Thread: [Linuxptp-users] Synchronization fault with stmmac
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users
|
From: BELAOUAD M. <mbe...@ad...> - 2014-03-17 17:02:23
|
Hi all :), I am new here but following you for 2 months since the beginning of my internship :p. Enough for the introduction, let's get real. I am using a Cyclone V from Altera (dual ARM Cortex A9 + FPGA) which includes a GMAC. The MAC supports HW timestamping and is used with the stmmac driver (same IP but slightly modified). My setup is the following: PC (SW timestamping) <--------> switch <------> Board (HW timestamping) ptp4l gives a Synchronization Fault with Hardware timestamping. Everything is fine with Software timestamping. I tried to set pi_offset_const to 1.0 but the clock still jumps backward somehow. Could you please help me on this matter and point me to possible sources of this problem? On a side note, does anyone use linuxptp with HW timestamping on stmmac successfully? Below is the log with -l 7. Please let me know if you need further information. Thanks, Mohamed # ./ptp4l -i eth0 -H -f test.cfg ptp4l[147.489]: selected /dev/ptp0 as PTP clock ptp4l[147.515]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[147.515]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[148.459]: port 1: new foreign master d48564.fffe.0b41d0-1 ptp4l[152.457]: selected best master clock d48564.fffe.0b41d0 ptp4l[152.457]: foreign master not using PTP timescale ptp4l[152.458]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[153.546]: master offset -1395073665119852258 s0 freq +0 path delay 85828161 ptp4l[154.459]: master offset -1395073665720073020 s1 freq -32767999 path delay 85828161 ptp4l[155.459]: master offset -587136672 s2 freq -32767999 path delay 85828161 ptp4l[155.459]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[156.458]: clockcheck: clock jumped backward or running slower than expected! ptp4l[156.458]: master offset -1237588174 s0 freq -32767999 path delay 149160250 ptp4l[156.459]: port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT ptp4l[157.458]: clockcheck: clock jumped backward or running slower than expected! ptp4l[157.458]: master offset -1824727375 s0 freq -32767999 path delay 149160250 ptp4l[158.457]: clockcheck: clock jumped backward or running slower than expected! ptp4l[158.458]: master offset -2348516905 s0 freq -32767999 path delay 85828161 ptp4l[159.457]: clockcheck: clock jumped backward or running slower than expected! ptp4l[159.457]: master offset -2935665289 s0 freq -32767999 path delay 85828161 ptp4l[160.457]: clockcheck: clock jumped backward or running slower than expected! ptp4l[160.457]: master offset -3522777179 s0 freq -32767999 path delay 85828161 ptp4l[161.456]: clockcheck: clock jumped backward or running slower than expected! ptp4l[161.456]: master offset -4148584796 s0 freq -32767999 path delay 124477361 ptp4l[162.533]: clockcheck: clock jumped backward or running slower than expected! |
|
From: Keller, J. E <jac...@in...> - 2014-03-17 22:15:38
|
Hi! On Mon, 2014-03-17 at 17:46 +0100, BELAOUAD Mohamed wrote: > Hi all :), > > > > I am new here but following you for 2 months since the beginning of my > internship :p. > > Enough for the introduction, let's get real. I am using a Cyclone V > from Altera (dual ARM Cortex A9 + FPGA) which includes a GMAC. > The MAC supports HW timestamping and is used with the stmmac driver > (same IP but slightly modified). > What does slightly modified mean? > > > My setup is the following: > > PC (SW timestamping) <--------> switch <------> Board (HW > timestamping) > > > > ptp4l gives a Synchronization Fault with Hardware timestamping. > Everything is fine with Software timestamping. > > I tried to set pi_offset_const to 1.0 but the clock still jumps > backward somehow. > This is almost surely caused by the driver or hardware not doing the RightThing(tm), in regards to the clock on the MAC. I am concerned since you said "slightly modified" hardware what that all means... > > > Could you please help me on this matter and point me to possible > sources of this problem? > > On a side note, does anyone use linuxptp with HW timestamping on > stmmac successfully? > > > > Below is the log with -l 7. Please let me know if you need further > information. > Kernel version, and what driver you are using? Thanks, Jake > > > Thanks, > > > > Mohamed > > > > # ./ptp4l -i eth0 -H -f test.cfg > ptp4l[147.489]: selected /dev/ptp0 as PTP clock > ptp4l[147.515]: port 1: INITIALIZING to LISTENING on INITIALIZE > ptp4l[147.515]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[148.459]: port 1: new foreign master d48564.fffe.0b41d0-1 > ptp4l[152.457]: selected best master clock d48564.fffe.0b41d0 > ptp4l[152.457]: foreign master not using PTP timescale > ptp4l[152.458]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > ptp4l[153.546]: master offset -1395073665119852258 s0 freq +0 > path delay 85828161 > ptp4l[154.459]: master offset -1395073665720073020 s1 freq -32767999 > path delay 85828161 > ptp4l[155.459]: master offset -587136672 s2 freq -32767999 path delay > 85828161 > ptp4l[155.459]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED > ptp4l[156.458]: clockcheck: clock jumped backward or running slower > than expected! > ptp4l[156.458]: master offset -1237588174 s0 freq -32767999 path delay > 149160250 > ptp4l[156.459]: port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT > ptp4l[157.458]: clockcheck: clock jumped backward or running slower > than expected! > ptp4l[157.458]: master offset -1824727375 s0 freq -32767999 path delay > 149160250 > ptp4l[158.457]: clockcheck: clock jumped backward or running slower > than expected! > ptp4l[158.458]: master offset -2348516905 s0 freq -32767999 path delay > 85828161 > ptp4l[159.457]: clockcheck: clock jumped backward or running slower > than expected! > ptp4l[159.457]: master offset -2935665289 s0 freq -32767999 path delay > 85828161 > ptp4l[160.457]: clockcheck: clock jumped backward or running slower > than expected! > ptp4l[160.457]: master offset -3522777179 s0 freq -32767999 path delay > 85828161 > ptp4l[161.456]: clockcheck: clock jumped backward or running slower > than expected! > ptp4l[161.456]: master offset -4148584796 s0 freq -32767999 path delay > 124477361 > ptp4l[162.533]: clockcheck: clock jumped backward or running slower > than expected! > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Mohamed B. <mbe...@ad...> - 2014-03-18 08:31:32
|
Hi Jacob, ----- Mail original ----- > Hi! > > On Mon, 2014-03-17 at 17:46 +0100, BELAOUAD Mohamed wrote: > > Hi all :), > > > > I am new here but following you for 2 months since the beginning of my > > internship :p. > > > > Enough for the introduction, let's get real. I am using a Cyclone V > > from Altera (dual ARM Cortex A9 + FPGA) which includes a GMAC. > > The MAC supports HW timestamping and is used with the stmmac driver > > (same IP but slightly modified). > > > > What does slightly modified mean? The Hardware IP used in the Cyclone V is based on a Synopsys IP. Same goes for the IP covered by the stmmac driver. However, there are some extra registers and some at a different location or with a different size. For example, I had to modify the multicast Hash Table management in the driver since it was not receiving the multicast packets. The core registers of the IP are the same. To me, everything seems fine with the registers addresses related to the reception/transmit/timestamping. > > > > > My setup is the following: > > > > PC (SW timestamping) <--------> switch <------> Board (HW > > timestamping) > > > > ptp4l gives a Synchronization Fault with Hardware timestamping. > > Everything is fine with Software timestamping. > > > > I tried to set pi_offset_const to 1.0 but the clock still jumps > > backward somehow. > > > > This is almost surely caused by the driver or hardware not doing the > RightThing(tm), in regards to the clock on the MAC. I am concerned since > you said "slightly modified" hardware what that all means... Yes, I also guess it is coming from the driver. I just want to make sure that it is not a misconfiguration on my settings. As it is most likely the case and if you have any idea of the cause, do you think it is coming: - from the time management (adjust/set freq/time) - from the timestamping receive end on the hardware I think it is time to dig into the driver again (>,<). > > > > > > > Could you please help me on this matter and point me to possible > > sources of this problem? > > > > On a side note, does anyone use linuxptp with HW timestamping on > > stmmac successfully? > > > > > > > > Below is the log with -l 7. Please let me know if you need further > > information. > > > > Kernel version, and what driver you are using? I am using a 3.12 kernel from rocketboards.org git. It is a git repo with tweaks/patches for the Cyclone V and Altera is trying to push the changes upstream in the mainline. The driver, as mentioned, is stmmac from stmicro in the 3.12 kernel. > > Thanks, > Jake > > > > > Thanks, > > > > Mohamed > > Thanks for your help and your time, Mohamed > > > > > > # ./ptp4l -i eth0 -H -f test.cfg > > ptp4l[147.489]: selected /dev/ptp0 as PTP clock > > ptp4l[147.515]: port 1: INITIALIZING to LISTENING on INITIALIZE > > ptp4l[147.515]: port 0: INITIALIZING to LISTENING on INITIALIZE > > ptp4l[148.459]: port 1: new foreign master d48564.fffe.0b41d0-1 > > ptp4l[152.457]: selected best master clock d48564.fffe.0b41d0 > > ptp4l[152.457]: foreign master not using PTP timescale > > ptp4l[152.458]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > > ptp4l[153.546]: master offset -1395073665119852258 s0 freq +0 > > path delay 85828161 > > ptp4l[154.459]: master offset -1395073665720073020 s1 freq -32767999 > > path delay 85828161 > > ptp4l[155.459]: master offset -587136672 s2 freq -32767999 path delay > > 85828161 > > ptp4l[155.459]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED > > ptp4l[156.458]: clockcheck: clock jumped backward or running slower > > than expected! > > ptp4l[156.458]: master offset -1237588174 s0 freq -32767999 path delay > > 149160250 > > ptp4l[156.459]: port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT > > ptp4l[157.458]: clockcheck: clock jumped backward or running slower > > than expected! > > ptp4l[157.458]: master offset -1824727375 s0 freq -32767999 path delay > > 149160250 > > ptp4l[158.457]: clockcheck: clock jumped backward or running slower > > than expected! > > ptp4l[158.458]: master offset -2348516905 s0 freq -32767999 path delay > > 85828161 > > ptp4l[159.457]: clockcheck: clock jumped backward or running slower > > than expected! > > ptp4l[159.457]: master offset -2935665289 s0 freq -32767999 path delay > > 85828161 > > ptp4l[160.457]: clockcheck: clock jumped backward or running slower > > than expected! > > ptp4l[160.457]: master offset -3522777179 s0 freq -32767999 path delay > > 85828161 > > ptp4l[161.456]: clockcheck: clock jumped backward or running slower > > than expected! > > ptp4l[161.456]: master offset -4148584796 s0 freq -32767999 path delay > > 124477361 > > ptp4l[162.533]: clockcheck: clock jumped backward or running slower > > than expected! > > > > > > ------------------------------------------------------------------------------ > > Learn Graph Databases - Download FREE O'Reilly Book > > "Graph Databases" is the definitive new guide to graph databases and their > > applications. Written by three acclaimed leaders in the field, > > this first edition is now available. Download your free book today! > > http://p.sf.net/sfu/13534_NeoTech > > _______________________________________________ > > Linuxptp-users mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > |
|
From: Keller, J. E <jac...@in...> - 2014-03-18 16:42:40
|
On Tue, 2014-03-18 at 09:31 +0100, Mohamed Belaouad wrote: > Hi Jacob, > > ----- Mail original ----- > > Hi! > > > > On Mon, 2014-03-17 at 17:46 +0100, BELAOUAD Mohamed wrote: > > > Hi all :), > > > > > > I am new here but following you for 2 months since the beginning of my > > > internship :p. > > > > > > Enough for the introduction, let's get real. I am using a Cyclone V > > > from Altera (dual ARM Cortex A9 + FPGA) which includes a GMAC. > > > The MAC supports HW timestamping and is used with the stmmac driver > > > (same IP but slightly modified). > > > > > > > What does slightly modified mean? > > The Hardware IP used in the Cyclone V is based on a Synopsys IP. Same goes for the IP covered by the stmmac driver. > However, there are some extra registers and some at a different location or with a different size. For example, I had to modify the multicast Hash Table management in the driver since it was not receiving the multicast packets. > > The core registers of the IP are the same. To me, everything seems fine with the registers addresses related to the reception/transmit/timestamping. > The error you are seeing is a clock sanity check. The clock is running slower than expected, or is jumping backwards. This could be caused by timing changes in the chip, though that is somewhat unlikely. Most likely you have a driver bug, misconfiguring the hardware and causing a jump. I would investigate the adjust frequency call, and the adjust time call.. It's also possible your timestamping code is incorrect (ie: not reading the values out correctly). My guess is some sort of overflow, possibly an overflow in the adjfreq's max ppb. My reasoning for this, is because it keeps on getting more negative offset. It will try to correct this by applying a large slew to the clock, which in turn has a negative impact on time, because it overflowed. I would investigate this first. You can use Documentation/ptp/testptp.c program to sanity check these ops. Thanks, Jake > > > > > > > > My setup is the following: > > > > > > PC (SW timestamping) <--------> switch <------> Board (HW > > > timestamping) > > > > > > ptp4l gives a Synchronization Fault with Hardware timestamping. > > > Everything is fine with Software timestamping. > > > > > > I tried to set pi_offset_const to 1.0 but the clock still jumps > > > backward somehow. > > > > > > > This is almost surely caused by the driver or hardware not doing the > > RightThing(tm), in regards to the clock on the MAC. I am concerned since > > you said "slightly modified" hardware what that all means... > > Yes, I also guess it is coming from the driver. I just want to make sure that it is not a misconfiguration on my settings. > > As it is most likely the case and if you have any idea of the cause, do you think it is coming: > - from the time management (adjust/set freq/time) > - from the timestamping receive end on the hardware > > I think it is time to dig into the driver again (>,<). > > > > > > > > > > > > Could you please help me on this matter and point me to possible > > > sources of this problem? > > > > > > On a side note, does anyone use linuxptp with HW timestamping on > > > stmmac successfully? > > > > > > > > > > > > Below is the log with -l 7. Please let me know if you need further > > > information. > > > > > > > Kernel version, and what driver you are using? > > I am using a 3.12 kernel from rocketboards.org git. It is a git repo with tweaks/patches for the Cyclone V and Altera is trying to push the changes upstream in the mainline. > The driver, as mentioned, is stmmac from stmicro in the 3.12 kernel. > > > > > Thanks, > > Jake > > > > > > > > Thanks, > > > > > > Mohamed > > > > > Thanks for your help and your time, > > Mohamed > > > > > > > > > > # ./ptp4l -i eth0 -H -f test.cfg > > > ptp4l[147.489]: selected /dev/ptp0 as PTP clock > > > ptp4l[147.515]: port 1: INITIALIZING to LISTENING on INITIALIZE > > > ptp4l[147.515]: port 0: INITIALIZING to LISTENING on INITIALIZE > > > ptp4l[148.459]: port 1: new foreign master d48564.fffe.0b41d0-1 > > > ptp4l[152.457]: selected best master clock d48564.fffe.0b41d0 > > > ptp4l[152.457]: foreign master not using PTP timescale > > > ptp4l[152.458]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > > > ptp4l[153.546]: master offset -1395073665119852258 s0 freq +0 > > > path delay 85828161 > > > ptp4l[154.459]: master offset -1395073665720073020 s1 freq -32767999 > > > path delay 85828161 > > > ptp4l[155.459]: master offset -587136672 s2 freq -32767999 path delay > > > 85828161 > > > ptp4l[155.459]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED > > > ptp4l[156.458]: clockcheck: clock jumped backward or running slower > > > than expected! > > > ptp4l[156.458]: master offset -1237588174 s0 freq -32767999 path delay > > > 149160250 > > > ptp4l[156.459]: port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT > > > ptp4l[157.458]: clockcheck: clock jumped backward or running slower > > > than expected! > > > ptp4l[157.458]: master offset -1824727375 s0 freq -32767999 path delay > > > 149160250 > > > ptp4l[158.457]: clockcheck: clock jumped backward or running slower > > > than expected! > > > ptp4l[158.458]: master offset -2348516905 s0 freq -32767999 path delay > > > 85828161 > > > ptp4l[159.457]: clockcheck: clock jumped backward or running slower > > > than expected! > > > ptp4l[159.457]: master offset -2935665289 s0 freq -32767999 path delay > > > 85828161 > > > ptp4l[160.457]: clockcheck: clock jumped backward or running slower > > > than expected! > > > ptp4l[160.457]: master offset -3522777179 s0 freq -32767999 path delay > > > 85828161 > > > ptp4l[161.456]: clockcheck: clock jumped backward or running slower > > > than expected! > > > ptp4l[161.456]: master offset -4148584796 s0 freq -32767999 path delay > > > 124477361 > > > ptp4l[162.533]: clockcheck: clock jumped backward or running slower > > > than expected! > > > > > > > > > ------------------------------------------------------------------------------ > > > Learn Graph Databases - Download FREE O'Reilly Book > > > "Graph Databases" is the definitive new guide to graph databases and their > > > applications. Written by three acclaimed leaders in the field, > > > this first edition is now available. Download your free book today! > > > http://p.sf.net/sfu/13534_NeoTech > > > _______________________________________________ > > > Linuxptp-users mailing list > > > Lin...@li... > > > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > > ------------------------------------------------------------------------------ > > Learn Graph Databases - Download FREE O'Reilly Book > > "Graph Databases" is the definitive new guide to graph databases and their > > applications. Written by three acclaimed leaders in the field, > > this first edition is now available. Download your free book today! > > http://p.sf.net/sfu/13534_NeoTech > > _______________________________________________ > > Linuxptp-users mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > |
|
From: Tony K. <tk...@ma...> - 2014-03-19 15:39:03
|
My system: kernel 3.10.17 stmmac driver In the file stmmac_hwstamp.c, in the function stmmac_config_sub_second_increment(), the clock rate is converted to nano seconds (using a formula that assumes the ptp_clock is 50Mhz) and then scaled depending on binary or digital rollover mode, and finally written to the sub second increment register. When I ponder the following line of code in this function (where "value" is previously-read Time Stamp Control Register): /* 0.465ns accuracy */ if (value & PTP_TCR_TSCTRLSSR) data = (data * 100) / 465; it says to me "if the PTP_TCR_TSCTRLSSR bit is SET (indicating digital rollover mode) then scale the sub-second increment value by .465 ns" I'm confused however, because it seems to me that if the TSCTRLSSR bit is CLEAR (indicating BINARY rollover mode) that's when we require the .465ns scale factor (yes? no?) Regards, Tony "puzzled" Klein MAX4G MPLS, MN > > As it is most likely the case and if you have any idea of the cause, do you think it is coming: > - from the time management (adjust/set freq/time) > - from the timestamping receive end on the hardware > > I think it is time to dig into the driver again (>,<). > |
|
From: Richard C. <ric...@gm...> - 2014-03-18 17:57:51
|
On Tue, Mar 18, 2014 at 09:31:19AM +0100, Mohamed Belaouad wrote: > The core registers of the IP are the same. To me, everything seems > fine with the registers addresses related to the > reception/transmit/timestamping. Did you consider that the input clock to the time function within the IP core might be at a different frequency than the driver expects? > Yes, I also guess it is coming from the driver. I just want to make > sure that it is not a misconfiguration on my settings. >From the git log of drivers/net/ethernet/stmicro/stmmac it appears that people have been using linuxptp with this driver and "normal" hardware. I would not discount the possibility that the Altera implementation is somehow buggy in hardware. > I think it is time to dig into the driver again (>,<). The first step is to see whether the basic clock operations work or not by using the testptp program. Thanks, Richard |
|
From: Mohamed B. <mbe...@ad...> - 2014-03-19 08:54:09
|
Hi Richard & Jake, //Richard > On Tue, Mar 18, 2014 at 09:31:19AM +0100, Mohamed Belaouad wrote: > > > The core registers of the IP are the same. To me, everything seems > > fine with the registers addresses related to the > > reception/transmit/timestamping. > > Did you consider that the input clock to the time function within the > IP core might be at a different frequency than the driver expects? > Yes, I thought about it at one point but was too much focused on the driver side that I forgot! Thanks for reminding me, I will investigate. >From the first test I did (running ptp4l to get the PC time then stopping it), the board ptp time seems to run slower than the PC time. While 5 minutes elapsed on the PC, 2/3min only do on the board. > > Yes, I also guess it is coming from the driver. I just want to make > > sure that it is not a misconfiguration on my settings. > > From the git log of drivers/net/ethernet/stmicro/stmmac it appears > that people have been using linuxptp with this driver and "normal" > hardware. I would not discount the possibility that the Altera > implementation is somehow buggy in hardware. > That's true even though I saw a not yet accepted patch of someone working with the Cyclone V and linuxptp. I may contact him if I don't find the cause. > > I think it is time to dig into the driver again (>,<). > > The first step is to see whether the basic clock operations work or > not by using the testptp program. I already did that yesterday. Everything seems fine on this side, set/get/shift time and adjust frequency. //Jake > The error you are seeing is a clock sanity check. The clock is running > slower than expected, or is jumping backwards. > > This could be caused by timing changes in the chip, though that is > somewhat unlikely. > > Most likely you have a driver bug, misconfiguring the hardware and > causing a jump. I would investigate the adjust frequency call, and the > adjust time call.. It's also possible your timestamping code is > incorrect (ie: not reading the values out correctly). The read & write timestamps are correct according to the prints I added in ptp4l and the packets in wireshark. > My guess is some > sort of overflow, possibly an overflow in the adjfreq's max ppb. My > reasoning for this, is because it keeps on getting more negative offset. > It will try to correct this by applying a large slew to the clock, which > in turn has a negative impact on time, because it overflowed. I would > investigate this first. > Adjust time seems fine since the board ptp clock sets at the PC clock. The adjust frequency however is quite strange. Printing the ppb passed to the driver gives +32,767,999 (corresponding to the -32,767,999 of the ptp4l log). After that, ptp4l still displays -32,767,999 so I guess something goes wrong on the driver/hardware side. It may be as Richard mentioned a different input clock or as you do with an overflow. > You can use Documentation/ptp/testptp.c program to sanity check these > ops. Done as mentioned. One strange thing which comes back is that the +32,767,999 passed to the driver with testptp gives an "okay". Actually, I just noticed the high level ptp driver always returns 0 even though the low level parts of it may return an error! I will get into that. There are so many unknowns that it may come from everywhere :). Thanks, Mohamed |
|
From: Richard C. <ric...@gm...> - 2014-03-19 09:46:33
|
On Wed, Mar 19, 2014 at 09:54:00AM +0100, Mohamed Belaouad wrote:
> From the first test I did (running ptp4l to get the PC time then
> stopping it), the board ptp time seems to run slower than the PC
> time. While 5 minutes elapsed on the PC, 2/3min only do on the
> board.
You can easily test the clock speed like this.
testptp -g
sleep 60
testptp -g
Then, see if 60 seconds elapsed.
Thanks,
Richard
|
|
From: Keller, J. E <jac...@in...> - 2014-03-19 18:18:45
|
On Wed, 2014-03-19 at 10:46 +0100, Richard Cochran wrote: > On Wed, Mar 19, 2014 at 09:54:00AM +0100, Mohamed Belaouad wrote: > > > From the first test I did (running ptp4l to get the PC time then > > stopping it), the board ptp time seems to run slower than the PC > > time. While 5 minutes elapsed on the PC, 2/3min only do on the > > board. > > You can easily test the clock speed like this. > > testptp -g > sleep 60 > testptp -g > > Then, see if 60 seconds elapsed. > > Thanks, > Richard Also test with various adjustment frequencies applied, I don't know exact commands here, but you can do something like: adjust frequency by 50% (500 million ppb) set clock to system time or 0 get time sleep some amount of time get time then check to see if the expected time adjusted by the frequency change has actually passed. In this way, you can see whether frequency adjustment is working right, since if you modify the clock frequency by say.. 1.5x, then you should see roughly an equivalent decrease in the time different on clock, of "time difference / 1.5". Please do these experiments using testptp first and see if things make sense. This will help limit the scope of the tests so you can see what parts might be failing. I would suggest attempting to set the ppb to the maximum value your driver allows as well, to check to see if the adjustment is overflowing somehow. Regards, Jake |
|
From: Mohamed B. <mbe...@ad...> - 2014-03-20 15:28:07
|
> On Wed, 2014-03-19 at 10:46 +0100, Richard Cochran wrote: > > On Wed, Mar 19, 2014 at 09:54:00AM +0100, Mohamed Belaouad wrote: > > > > > From the first test I did (running ptp4l to get the PC time then > > > stopping it), the board ptp time seems to run slower than the PC > > > time. While 5 minutes elapsed on the PC, 2/3min only do on the > > > board. > > > > You can easily test the clock speed like this. > > > > testptp -g > > sleep 60 > > testptp -g > > > > Then, see if 60 seconds elapsed. > > This is now working correctly after setting the correct frequencies in the driver. There is no more synchronization fault :). > > Also test with various adjustment frequencies applied, I don't know > exact commands here, but you can do something like: > > adjust frequency by 50% (500 million ppb) > set clock to system time or 0 > get time > sleep some amount of time > get time > > then check to see if the expected time adjusted by the frequency change > has actually passed. > > In this way, you can see whether frequency adjustment is working right, > since if you modify the clock frequency by say.. 1.5x, then you should > see roughly an equivalent decrease in the time different on clock, of > "time difference / 1.5". > > Please do these experiments using testptp first and see if things make > sense. This will help limit the scope of the tests so you can see what > parts might be failing. > > I would suggest attempting to set the ppb to the maximum value your > driver allows as well, to check to see if the adjustment is overflowing > somehow. The driver implementation is not checking the max frequency adjustment... I still did some tests and strange enough there is a value change to -32,768,000 when passing ppb greater than 32,768,000. Also, the value saturates to -32,768,000 with ppb lesser than -32,768,000. So I am forced to use values between [-32,768,000 | 32,768,000]. I guess your test suggestion will pass once I get through this. Could you please shed some light on that? Is it something related with the kernel ptp clock driver? I did not find The value received by the driver is the one after ppb: TEST PTP ADJ FREQ: # ./testptp -d /dev/ptp0 -f 32767999 [ADJ_FREQ 0] ppb:32767999 frequency adjustment okay # ./testptp -d /dev/ptp0 -f 32768000 [ADJ_FREQ 0] ppb:-32768000 frequency adjustment okay # ./testptp -d /dev/ptp0 -f -32768000 [ADJ_FREQ 0] ppb:-32768000 frequency adjustment okay # ./testptp -d /dev/ptp0 -f -32768001 [ADJ_FREQ 0] ppb:-32768000 frequency adjustment okay Thanks, Mohamed |
|
From: Keller, J. E <jac...@in...> - 2014-03-20 15:45:51
|
On Thu, 2014-03-20 at 16:27 +0100, Mohamed Belaouad wrote: > > > On Wed, 2014-03-19 at 10:46 +0100, Richard Cochran wrote: > > > On Wed, Mar 19, 2014 at 09:54:00AM +0100, Mohamed Belaouad wrote: > > > > > > > From the first test I did (running ptp4l to get the PC time then > > > > stopping it), the board ptp time seems to run slower than the PC > > > > time. While 5 minutes elapsed on the PC, 2/3min only do on the > > > > board. > > > > > > You can easily test the clock speed like this. > > > > > > testptp -g > > > sleep 60 > > > testptp -g > > > > > > Then, see if 60 seconds elapsed. > > > > > This is now working correctly after setting the correct frequencies in the driver. There is no more synchronization fault :). > > > > > Also test with various adjustment frequencies applied, I don't know > > exact commands here, but you can do something like: > > > > adjust frequency by 50% (500 million ppb) > > set clock to system time or 0 > > get time > > sleep some amount of time > > get time > > > > then check to see if the expected time adjusted by the frequency change > > has actually passed. > > > > In this way, you can see whether frequency adjustment is working right, > > since if you modify the clock frequency by say.. 1.5x, then you should > > see roughly an equivalent decrease in the time different on clock, of > > "time difference / 1.5". > > > > Please do these experiments using testptp first and see if things make > > sense. This will help limit the scope of the tests so you can see what > > parts might be failing. > > > > I would suggest attempting to set the ppb to the maximum value your > > driver allows as well, to check to see if the adjustment is overflowing > > somehow. > > The driver implementation is not checking the max frequency adjustment... > I still did some tests and strange enough there is a value change to -32,768,000 when passing ppb greater than 32,768,000. Also, the value saturates to -32,768,000 with ppb lesser than -32,768,000. > So I am forced to use values between [-32,768,000 | 32,768,000]. I guess your test suggestion will pass once I get through this. > > Could you please shed some light on that? Is it something related with the kernel ptp clock driver? I did not find > > The value received by the driver is the one after ppb: > TEST PTP ADJ FREQ: > # ./testptp -d /dev/ptp0 -f 32767999 > [ADJ_FREQ 0] ppb:32767999 > frequency adjustment okay > # ./testptp -d /dev/ptp0 -f 32768000 > [ADJ_FREQ 0] ppb:-32768000 > frequency adjustment okay > # ./testptp -d /dev/ptp0 -f -32768000 > [ADJ_FREQ 0] ppb:-32768000 > frequency adjustment okay > # ./testptp -d /dev/ptp0 -f -32768001 > [ADJ_FREQ 0] ppb:-32768000 > frequency adjustment okay > Out of curiosity where are you printing the value ppb? Thanks, Jake > Thanks, > Mohamed |
|
From: Keller, J. E <jac...@in...> - 2014-03-20 15:46:17
|
On Thu, 2014-03-20 at 16:27 +0100, Mohamed Belaouad wrote: > > > On Wed, 2014-03-19 at 10:46 +0100, Richard Cochran wrote: > > > On Wed, Mar 19, 2014 at 09:54:00AM +0100, Mohamed Belaouad wrote: > > > > > > > From the first test I did (running ptp4l to get the PC time then > > > > stopping it), the board ptp time seems to run slower than the PC > > > > time. While 5 minutes elapsed on the PC, 2/3min only do on the > > > > board. > > > > > > You can easily test the clock speed like this. > > > > > > testptp -g > > > sleep 60 > > > testptp -g > > > > > > Then, see if 60 seconds elapsed. > > > > > This is now working correctly after setting the correct frequencies in the driver. There is no more synchronization fault :). > > > > > Also test with various adjustment frequencies applied, I don't know > > exact commands here, but you can do something like: > > > > adjust frequency by 50% (500 million ppb) > > set clock to system time or 0 > > get time > > sleep some amount of time > > get time > > > > then check to see if the expected time adjusted by the frequency change > > has actually passed. > > > > In this way, you can see whether frequency adjustment is working right, > > since if you modify the clock frequency by say.. 1.5x, then you should > > see roughly an equivalent decrease in the time different on clock, of > > "time difference / 1.5". > > > > Please do these experiments using testptp first and see if things make > > sense. This will help limit the scope of the tests so you can see what > > parts might be failing. > > > > I would suggest attempting to set the ppb to the maximum value your > > driver allows as well, to check to see if the adjustment is overflowing > > somehow. > > The driver implementation is not checking the max frequency adjustment... > I still did some tests and strange enough there is a value change to -32,768,000 when passing ppb greater than 32,768,000. Also, the value saturates to -32,768,000 with ppb lesser than -32,768,000. > So I am forced to use values between [-32,768,000 | 32,768,000]. I guess your test suggestion will pass once I get through this. > > Could you please shed some light on that? Is it something related with the kernel ptp clock driver? I did not find > Your driver does have to fill in the maximum value to register to the ptp core, and ptp core handles checking, but maybe there is a bug regarding that in your kernel... It should be keeping the sign the same when it clips the maximum value, however. It should be changing it to the max adjust, non negative. Look at your driver, where you set the max_adj field of ptp_caps. Thanks, Jake > > The value received by the driver is the one after ppb: > TEST PTP ADJ FREQ: > # ./testptp -d /dev/ptp0 -f 32767999 > [ADJ_FREQ 0] ppb:32767999 > frequency adjustment okay > # ./testptp -d /dev/ptp0 -f 32768000 > [ADJ_FREQ 0] ppb:-32768000 > frequency adjustment okay > # ./testptp -d /dev/ptp0 -f -32768000 > [ADJ_FREQ 0] ppb:-32768000 > frequency adjustment okay > # ./testptp -d /dev/ptp0 -f -32768001 > [ADJ_FREQ 0] ppb:-32768000 > frequency adjustment okay > > Thanks, > Mohamed |
|
From: Mohamed B. <mbe...@ad...> - 2014-03-20 17:03:27
|
Jake, > Out of curiosity where are you printing the value ppb? I am printing right at the beginning of stmmac_adjust_freq function (drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c). So the value should be clean. > > > > The driver implementation is not checking the max frequency adjustment... > > I still did some tests and strange enough there is a value change to > > -32,768,000 when passing ppb greater than 32,768,000. Also, the value > > saturates to -32,768,000 with ppb lesser than -32,768,000. > > So I am forced to use values between [-32,768,000 | 32,768,000]. I guess > > your test suggestion will pass once I get through this. > > > > Could you please shed some light on that? Is it something related with the > > kernel ptp clock driver? I did not find > > > > Your driver does have to fill in the maximum value to register to the > ptp core, and ptp core handles checking, but maybe there is a bug > regarding that in your kernel... It should be keeping the sign the same > when it clips the maximum value, however. > > It should be changing it to the max adjust, non negative. > > Look at your driver, where you set the max_adj field of ptp_caps. > It is correctly filled with 62,500,000 and I checked with testptp. So there is still some margin. I don't know if I am looking at the right location but I did not find any check on max_adj of ppb in drivers/ptp. Thanks, Mohamed |
|
From: Keller, J. E <jac...@in...> - 2014-03-20 17:42:33
|
On Thu, 2014-03-20 at 18:03 +0100, Mohamed Belaouad wrote: > Jake, > > > Out of curiosity where are you printing the value ppb? > > I am printing right at the beginning of stmmac_adjust_freq function (drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c). > So the value should be clean. > > > > > > > The driver implementation is not checking the max frequency adjustment... > > > I still did some tests and strange enough there is a value change to > > > -32,768,000 when passing ppb greater than 32,768,000. Also, the value > > > saturates to -32,768,000 with ppb lesser than -32,768,000. > > > So I am forced to use values between [-32,768,000 | 32,768,000]. I guess > > > your test suggestion will pass once I get through this. > > > > > > Could you please shed some light on that? Is it something related with the > > > kernel ptp clock driver? I did not find > > > > > > > Your driver does have to fill in the maximum value to register to the > > ptp core, and ptp core handles checking, but maybe there is a bug > > regarding that in your kernel... It should be keeping the sign the same > > when it clips the maximum value, however. > > > > It should be changing it to the max adjust, non negative. > > > > Look at your driver, where you set the max_adj field of ptp_caps. > > > > It is correctly filled with 62,500,000 and I checked with testptp. So there is still some margin. > I don't know if I am looking at the right location but I did not find any check on max_adj of ppb in drivers/ptp. > > > Thanks, > Mohamed That's interesting.. It's possible you have a bug in the kernel you are using.. That'd be my only suggestion.. Maybe Richard who wrote the ptp core module knows more about this.. Thanks, Jake |
|
From: Mohamed B. <mbe...@ad...> - 2014-03-25 08:16:16
|
Richard, Could you please give us your insight on this matter? I would appreciate any lead to pinpoint the cause :). Thanks & Best Regards, Mohamed > On Thu, 2014-03-20 at 18:03 +0100, Mohamed Belaouad wrote: > > Jake, > > > > > Out of curiosity where are you printing the value ppb? > > > > I am printing right at the beginning of stmmac_adjust_freq function > > (drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c). > > So the value should be clean. > > > > > > > > > > The driver implementation is not checking the max frequency > > > > adjustment... > > > > I still did some tests and strange enough there is a value change to > > > > -32,768,000 when passing ppb greater than 32,768,000. Also, the value > > > > saturates to -32,768,000 with ppb lesser than -32,768,000. > > > > So I am forced to use values between [-32,768,000 | 32,768,000]. I > > > > guess > > > > your test suggestion will pass once I get through this. > > > > > > > > Could you please shed some light on that? Is it something related with > > > > the > > > > kernel ptp clock driver? I did not find > > > > > > > > > > Your driver does have to fill in the maximum value to register to the > > > ptp core, and ptp core handles checking, but maybe there is a bug > > > regarding that in your kernel... It should be keeping the sign the same > > > when it clips the maximum value, however. > > > > > > It should be changing it to the max adjust, non negative. > > > > > > Look at your driver, where you set the max_adj field of ptp_caps. > > > > > > > It is correctly filled with 62,500,000 and I checked with testptp. So there > > is still some margin. > > I don't know if I am looking at the right location but I did not find any > > check on max_adj of ppb in drivers/ptp. > > > > > > Thanks, > > Mohamed > > That's interesting.. It's possible you have a bug in the kernel you are > using.. That'd be my only suggestion.. Maybe Richard who wrote the ptp > core module knows more about this.. > > Thanks, > Jake > |
|
From: Richard C. <ric...@gm...> - 2014-03-25 08:40:03
|
On Tue, Mar 25, 2014 at 09:16:07AM +0100, Mohamed Belaouad wrote: > Richard, > > Could you please give us your insight on this matter? > I would appreciate any lead to pinpoint the cause :). The cause of what? Thanks, Richard |
|
From: Mohamed B. <mbe...@ad...> - 2014-03-25 08:52:43
|
Thanks for your fast answer Richard, Please see the discussion with Jake below regarding a saturation of the ppb adjustment. To sum up, the ppb adjustment passed to the driver is limited to [-32,768,000 | 32,768,000] and when passing values > 32,768,000 it saturates to -32,768,000. Also, what we would like to know is: is the max ppb adjustment check done in the PTP subsystem (I have not found anything about it in drivers/ptp, maybe wrong location?) or should it be handled in the driver? > > > Out of curiosity where are you printing the value ppb? > > > > I am printing right at the beginning of stmmac_adjust_freq function > > (drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c). > > So the value should be clean. > > > > > > > > > > The driver implementation is not checking the max frequency > > > > adjustment... > > > > I still did some tests and strange enough there is a value change to > > > > -32,768,000 when passing ppb greater than 32,768,000. Also, the value > > > > saturates to -32,768,000 with ppb lesser than -32,768,000. > > > > So I am forced to use values between [-32,768,000 | 32,768,000]. I > > > > guess > > > > your test suggestion will pass once I get through this. > > > > > > > > Could you please shed some light on that? Is it something related with > > > > the > > > > kernel ptp clock driver? I did not find > > > > > > > > > > Your driver does have to fill in the maximum value to register to the > > > ptp core, and ptp core handles checking, but maybe there is a bug > > > regarding that in your kernel... It should be keeping the sign the same > > > when it clips the maximum value, however. > > > > > > It should be changing it to the max adjust, non negative. > > > > > > Look at your driver, where you set the max_adj field of ptp_caps. > > > > > > > It is correctly filled with 62,500,000 and I checked with testptp. So there > > is still some margin. > > I don't know if I am looking at the right location but I did not find any > > check on max_adj of ppb in drivers/ptp. > > > > > > Thanks, > > Mohamed > > That's interesting.. It's possible you have a bug in the kernel you are > using.. That'd be my only suggestion.. Maybe Richard who wrote the ptp > core module knows more about this.. > > Thanks, > Jake Thanks & Best Regards, Mohamed |
|
From: Richard C. <ric...@gm...> - 2014-03-25 11:30:13
|
On Tue, Mar 25, 2014 at 09:52:32AM +0100, Mohamed Belaouad wrote: > To sum up, the ppb adjustment passed to the driver is limited to > [-32,768,000 | 32,768,000] and when passing values > 32,768,000 it > saturates to -32,768,000. Why are you passing values greater than what the device can handle? That doesn't make sense to do, and we don't do it in ptp4l. > Also, what we would like to know is: is the max ppb adjustment check > done in the PTP subsystem (I have not found anything about it in > drivers/ptp, maybe wrong location?) or should it be handled in the > driver? There is no check in the kernel. I guess that ptp_clock_adjtime could return ERANGE in such a case. You do realize that all of this has nothing to do with your stmmac troubles, don't you? Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2014-03-25 11:56:40
|
On Tue, Mar 25, 2014 at 12:30:01PM +0100, Richard Cochran wrote:
> On Tue, Mar 25, 2014 at 09:52:32AM +0100, Mohamed Belaouad wrote:
>
> > Also, what we would like to know is: is the max ppb adjustment check
> > done in the PTP subsystem (I have not found anything about it in
> > drivers/ptp, maybe wrong location?) or should it be handled in the
> > driver?
>
> There is no check in the kernel. I guess that ptp_clock_adjtime could
> return ERANGE in such a case.
Is this (untested patch) what you are asking for?
Thanks,
Richard
---
diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
index e25d2bc..239d02f 100644
--- a/drivers/ptp/ptp_clock.c
+++ b/drivers/ptp/ptp_clock.c
@@ -142,7 +142,10 @@ static int ptp_clock_adjtime(struct posix_clock *pc, struct timex *tx)
delta = ktime_to_ns(kt);
err = ops->adjtime(ops, delta);
} else if (tx->modes & ADJ_FREQUENCY) {
- err = ops->adjfreq(ops, scaled_ppm_to_ppb(tx->freq));
+ s32 delta = scaled_ppm_to_ppb(tx->freq);
+ if (delta > ops->max_adj || delta < -ops->max_adj)
+ return -ERANGE;
+ err = ops->adjfreq(ops, delta);
ptp->dialed_frequency = tx->freq;
} else if (tx->modes == 0) {
tx->freq = ptp->dialed_frequency;
|
|
From: Mohamed B. <mbe...@ad...> - 2014-03-25 13:38:38
|
Richard,
Thank you for the insight on the kernel ptp management.
As I stated, the driver was corrected and ptp4l is working correctly. There is no more issue on this part.
I also do realize it is not related to the problems I had with stmmac. This is for my knowledge of linux ptp driver, stmmac driver, testptp and ptp4l.
So please let me rephrase since my words may have been confusing. The only "issue" remaining is the one I mentioned with the max ppb and testptp.
Considering that the drivers sets the max adj to 62,500,000, I should be able to set the ppb ajustment up/down to -+62,500,000 from my understanding.
However, when printing the value passed to the driver with testptp I get:
Value passed to testptp | Value printed at the entry of the driver function
> +32,768,000 | -32,768,000
< -32,768,000 | -32,768,000
This explains why I asked you if it is handled in the kernel (as I did not find such a code snippet in drivers/ptp). From what you told me it seems to be in ptp4l, I will have a look.
Please excuse me if it is a misunderstanding on my part.
> On Tue, Mar 25, 2014 at 09:52:32AM +0100, Mohamed Belaouad wrote:
>
> > To sum up, the ppb adjustment passed to the driver is limited to
> > [-32,768,000 | 32,768,000] and when passing values > 32,768,000 it
> > saturates to -32,768,000.
>
> Why are you passing values greater than what the device can handle?
> That doesn't make sense to do, and we don't do it in ptp4l.
>
> > Also, what we would like to know is: is the max ppb adjustment check
> > done in the PTP subsystem (I have not found anything about it in
> > drivers/ptp, maybe wrong location?) or should it be handled in the
> > driver?
>
> There is no check in the kernel. I guess that ptp_clock_adjtime could
> return ERANGE in such a case.
>
> You do realize that all of this has nothing to do with your stmmac
> troubles, don't you?
Thanks & Best Regards,
Mohamed
|
|
From: Richard C. <ric...@gm...> - 2014-03-25 14:29:29
|
On Tue, Mar 25, 2014 at 02:38:29PM +0100, Mohamed Belaouad wrote: > Considering that the drivers sets the max adj to 62,500,000, I > should be able to set the ppb ajustment up/down to -+62,500,000 from > my understanding. Yes, that is correct. > However, when printing the value passed to the driver with testptp I get: > Value passed to testptp | Value printed at the entry of the driver function > > +32,768,000 | -32,768,000 > < -32,768,000 | -32,768,000 I guess you are on a 32 bit platform. In that case, the size of the adjustment is limited by the timex.freq field. See linuxptp/phc.c. > Please excuse me if it is a misunderstanding on my part. I thought you meant that the kernel should check that the dialed frequency offset is within the bounds of [-max_adj, +max_adj]. That is a different issue. Thanks, Richard |
|
From: Mohamed B. <mbe...@ad...> - 2014-03-25 16:16:41
|
I really appreciate that you and Jake helped me on my issues. > I guess you are on a 32 bit platform. In that case, the size of the > adjustment is limited by the timex.freq field. See linuxptp/phc.c. > Yes, I am. I was on the right track and understand now. Thanks to both of you & Best Regards, Mohamed |
|
From: Keller, J. E <jac...@in...> - 2014-03-25 16:35:38
|
On Tue, 2014-03-25 at 15:29 +0100, Richard Cochran wrote: > On Tue, Mar 25, 2014 at 02:38:29PM +0100, Mohamed Belaouad wrote: > > > Considering that the drivers sets the max adj to 62,500,000, I > > should be able to set the ppb ajustment up/down to -+62,500,000 from > > my understanding. > > Yes, that is correct. > > > However, when printing the value passed to the driver with testptp I get: > > Value passed to testptp | Value printed at the entry of the driver function > > > +32,768,000 | -32,768,000 > > < -32,768,000 | -32,768,000 > > I guess you are on a 32 bit platform. In that case, the size of the > adjustment is limited by the timex.freq field. See linuxptp/phc.c. > > > Please excuse me if it is a misunderstanding on my part. > > I thought you meant that the kernel should check that the dialed > frequency offset is within the bounds of [-max_adj, +max_adj]. > That is a different issue. > I think that change to the kernel would be a good thing, since most drivers assume that the value passed to them is within range. Regards, Jake > Thanks, > Richard > |
|
From: Mohamed B. <mbe...@ad...> - 2014-03-26 07:57:43
|
I agree with you. Either that or the drivers could return an error in such a case. Best Regards, Mohamed ----- Mail original ----- > On Tue, 2014-03-25 at 15:29 +0100, Richard Cochran wrote: > > On Tue, Mar 25, 2014 at 02:38:29PM +0100, Mohamed Belaouad wrote: > > > > > Considering that the drivers sets the max adj to 62,500,000, I > > > should be able to set the ppb ajustment up/down to -+62,500,000 from > > > my understanding. > > > > Yes, that is correct. > > > > > However, when printing the value passed to the driver with testptp I get: > > > Value passed to testptp | Value printed at the entry of the driver > > > function > > > > +32,768,000 | -32,768,000 > > > < -32,768,000 | -32,768,000 > > > > I guess you are on a 32 bit platform. In that case, the size of the > > adjustment is limited by the timex.freq field. See linuxptp/phc.c. > > > > > Please excuse me if it is a misunderstanding on my part. > > > > I thought you meant that the kernel should check that the dialed > > frequency offset is within the bounds of [-max_adj, +max_adj]. > > That is a different issue. > > > > I think that change to the kernel would be a good thing, since most > drivers assume that the value passed to them is within range. > > Regards, > Jake > > > Thanks, > > Richard > > > > > |
|
From: Keller, J. E <jac...@in...> - 2014-03-26 20:39:19
|
I would rather have this check in the ptp core, because it wouldn't rely on drivers doing it, and we'd only have to code it in one place. On Wed, 2014-03-26 at 08:57 +0100, Mohamed Belaouad wrote: > I agree with you. Either that or the drivers could return an error in such a case. > > Best Regards, > Mohamed > > ----- Mail original ----- > > On Tue, 2014-03-25 at 15:29 +0100, Richard Cochran wrote: > > > On Tue, Mar 25, 2014 at 02:38:29PM +0100, Mohamed Belaouad wrote: > > > > > > > Considering that the drivers sets the max adj to 62,500,000, I > > > > should be able to set the ppb ajustment up/down to -+62,500,000 from > > > > my understanding. > > > > > > Yes, that is correct. > > > > > > > However, when printing the value passed to the driver with testptp I get: > > > > Value passed to testptp | Value printed at the entry of the driver > > > > function > > > > > +32,768,000 | -32,768,000 > > > > < -32,768,000 | -32,768,000 > > > > > > I guess you are on a 32 bit platform. In that case, the size of the > > > adjustment is limited by the timex.freq field. See linuxptp/phc.c. > > > > > > > Please excuse me if it is a misunderstanding on my part. > > > > > > I thought you meant that the kernel should check that the dialed > > > frequency offset is within the bounds of [-max_adj, +max_adj]. > > > That is a different issue. > > > > > > > I think that change to the kernel would be a good thing, since most > > drivers assume that the value passed to them is within range. > > > > Regards, > > Jake > > > > > Thanks, > > > Richard > > > > > > > > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X