Thread: [Linuxptp-users] Hardware PTP clock synchronization
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users
|
From: Гаврилов А. <le...@im...> - 2013-08-01 07:57:24
|
Hello! I encountered a problem while obtaining the time from the adapter Intel pro1000 (82576). I use Fedora 18 kernel version 3.9.6. The values of the time I get through clock_gettime (id, timevalue) for the device / dev/ptp0. The source of the PTP packet is switch Hirschmann MAR1140. Wireshark shows the presence of all necessary for the implementation of the protocol PTP packets at the input adapter interface, but the time in the PTP counters are not adjusted in accordance with the values of the packages. I compiled linuxptp-1.2 downloaded from http://linuxptp.sourceforge.net/ and run the following commands: Hardware timestamping: # ptp4l -i p16p1 -p /dev/ptp0 -m -2 -H ptp4l[3704.267]: selected /dev/ptp0 as PTP clock ptp4l[3704.278]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[3704.278]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[3705.077]: port 1: new foreign master ece555.fffe.2de639-2 ptp4l[3709.401]: selected best master clock ece555.fffe.2de639 ptp4l[3709.401]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[3710.039]: recvmsg tx timestamp failed: Resource temporarily unavailable ptp4l[3710.039]: port 1: send delay request failed ptp4l[3710.039]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED ptp4l[3725.690]: port 1: FAULTY to LISTENING on FAULT_CLEARED ptp4l[3726.698]: port 1: new foreign master ece555.fffe.2de639-2 ptp4l[3731.022]: selected best master clock ece555.fffe.2de639 ptp4l[3731.022]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[3731.193]: recvmsg tx timestamp failed: Resource temporarily unavailable ptp4l[3731.193]: port 1: send delay request failed ptp4l[3731.193]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED Software timestamping: # ptp4l -i p16p1 -p /dev/ptp0 -m -2 -S ptp4l[3826.218]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[3826.218]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[3828.312]: port 1: new foreign master ece555.fffe.2de639-2 ptp4l[3832.218]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[3832.636]: selected best master clock ece555.fffe.2de639 ptp4l[3832.636]: port 1: MASTER to UNCALIBRATED on RS_SLAVE ptp4l[3833.805]: negative path delay -3374260 ptp4l[3833.805]: path_delay = (t2 - t3) + (t4 - t1) ptp4l[3833.805]: t2 - t3 = -87573969 ptp4l[3833.805]: t4 - t1 = +80825448 ptp4l[3833.805]: c1 0 ptp4l[3833.805]: c2 0 ptp4l[3833.805]: c3 0 ptp4l[3833.805]: port 1: minimum delay request interval 2^3 ptp4l[3834.628]: negative path delay -35159469 ptp4l[3834.628]: path_delay = (t2 - t3) + (t4 - t1) ptp4l[3834.628]: t2 - t3 = -910670474 ptp4l[3834.628]: t4 - t1 = +840351536 ptp4l[3834.628]: c1 0 ptp4l[3834.628]: c2 0 ptp4l[3834.628]: c3 0 ptp4l[3834.798]: master offset -10774702751233 s0 adj +0 path delay -19266864 ptp4l[3835.879]: master offset -10774619261329 s0 adj +0 path delay -19266864 What is the difference between hardware and software timestamping in this case? Why Hardware timestamping is not working properly? Why software timestamping shows the correct time values, but does not synchronize time with hardware ptp clock (/dev/ptp0)? Sincerely, Alexander. |
|
From: Keller, J. E <jac...@in...> - 2013-08-01 17:44:47
|
> -----Original Message----- > From: Гаврилов Александр [mailto:le...@im...] > Sent: Thursday, August 01, 2013 12:55 AM > To: lin...@li... > Subject: [Linuxptp-users] Hardware PTP clock synchronization > > Hello! > > I encountered a problem while obtaining the time from the adapter Intel > pro1000 (82576). > I use Fedora 18 kernel version 3.9.6. > The values of the time I get through clock_gettime (id, timevalue) for the > device / dev/ptp0. > The source of the PTP packet is switch Hirschmann MAR1140. Wireshark > shows the presence of all necessary for the implementation of the > protocol PTP packets at the input adapter interface, > but the time in the PTP counters are not adjusted in accordance with the > values of the packages. > I compiled linuxptp-1.2 downloaded from > http://linuxptp.sourceforge.net/ and run the following commands: > > Hardware timestamping: > > # ptp4l -i p16p1 -p /dev/ptp0 -m -2 -H > You are on a modern kernel. Please do not use -p /dev/ptpX option. Let the program automatically determine it. It may be the case that you don't have the right ptp device. Richard: do we have a check in place to ensure the passed argument is correct if we can check? I don't remember. > ptp4l[3704.267]: selected /dev/ptp0 as PTP clock > ptp4l[3704.278]: port 1: INITIALIZING to LISTENING on INITIALIZE > ptp4l[3704.278]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[3705.077]: port 1: new foreign master ece555.fffe.2de639-2 > ptp4l[3709.401]: selected best master clock ece555.fffe.2de639 > ptp4l[3709.401]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > ptp4l[3710.039]: recvmsg tx timestamp failed: Resource temporarily > unavailable This means your tx timestamp is not being properly detected. I don't know for sure why this is, but there are a few reasons. I will forward this to the intel engineer who designed the driver for this part. > ptp4l[3710.039]: port 1: send delay request failed > ptp4l[3710.039]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED > ptp4l[3725.690]: port 1: FAULTY to LISTENING on FAULT_CLEARED > ptp4l[3726.698]: port 1: new foreign master ece555.fffe.2de639-2 > ptp4l[3731.022]: selected best master clock ece555.fffe.2de639 > ptp4l[3731.022]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > ptp4l[3731.193]: recvmsg tx timestamp failed: Resource temporarily > unavailable > ptp4l[3731.193]: port 1: send delay request failed > ptp4l[3731.193]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED > hardware timestamping is not working correctly because you are not properly receiving the tx timestamps. > Software timestamping: > > # ptp4l -i p16p1 -p /dev/ptp0 -m -2 -S > > ptp4l[3826.218]: port 1: INITIALIZING to LISTENING on INITIALIZE > ptp4l[3826.218]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[3828.312]: port 1: new foreign master ece555.fffe.2de639-2 > ptp4l[3832.218]: port 1: LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > ptp4l[3832.636]: selected best master clock ece555.fffe.2de639 > ptp4l[3832.636]: port 1: MASTER to UNCALIBRATED on RS_SLAVE > ptp4l[3833.805]: negative path delay -3374260 > ptp4l[3833.805]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[3833.805]: t2 - t3 = -87573969 > ptp4l[3833.805]: t4 - t1 = +80825448 > ptp4l[3833.805]: c1 0 > ptp4l[3833.805]: c2 0 > ptp4l[3833.805]: c3 0 > ptp4l[3833.805]: port 1: minimum delay request interval 2^3 > ptp4l[3834.628]: negative path delay -35159469 > ptp4l[3834.628]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[3834.628]: t2 - t3 = -910670474 > ptp4l[3834.628]: t4 - t1 = +840351536 > ptp4l[3834.628]: c1 0 > ptp4l[3834.628]: c2 0 > ptp4l[3834.628]: c3 0 > ptp4l[3834.798]: master offset -10774702751233 s0 adj +0 path delay > -19266864 > ptp4l[3835.879]: master offset -10774619261329 s0 adj +0 path delay > -19266864 > > > What is the difference between hardware and software timestamping in > this case? > Why Hardware timestamping is not working properly? > Why software timestamping shows the correct time values, but does not > synchronize time with hardware ptp clock (/dev/ptp0)? > Hardware timestamping uses the ptp device, and coordinates with the driver for doing timestamps in the MAC or PHY. Software timestamping does software based stamps as late as possible in the driver. It does not use the PHC device at all and directly modifies the kernel time. They are completely different modes. > Sincerely, Alexander. > > Thanks, Jake |
|
From: Keller, J. E <jac...@in...> - 2013-08-01 17:50:12
|
> -----Original Message----- > From: Гаврилов Александр [mailto:le...@im...] > Sent: Thursday, August 01, 2013 12:55 AM > To: lin...@li... > Subject: [Linuxptp-users] Hardware PTP clock synchronization > > Hello! > > I encountered a problem while obtaining the time from the adapter Intel > pro1000 (82576). > I use Fedora 18 kernel version 3.9.6. > The values of the time I get through clock_gettime (id, timevalue) for the > device / dev/ptp0. > The source of the PTP packet is switch Hirschmann MAR1140. Wireshark > shows the presence of all necessary for the implementation of the > protocol PTP packets at the input adapter interface, > but the time in the PTP counters are not adjusted in accordance with the > values of the packages. > I compiled linuxptp-1.2 downloaded from > http://linuxptp.sourceforge.net/ and run the following commands: > > Hardware timestamping: > > # ptp4l -i p16p1 -p /dev/ptp0 -m -2 -H > Also please re-try with -P, for peer to peer delay mechanism. The 82576 does not always perform well when using E2E and can potentially drop packets due to its internal timestamping design having some flaws. See if it starts working if you can use peer delay mechanism? If your ptp source cannot use P2P, hopefully we can find out why E2E isn't working for you... - Jake > ptp4l[3704.267]: selected /dev/ptp0 as PTP clock > ptp4l[3704.278]: port 1: INITIALIZING to LISTENING on INITIALIZE > ptp4l[3704.278]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[3705.077]: port 1: new foreign master ece555.fffe.2de639-2 > ptp4l[3709.401]: selected best master clock ece555.fffe.2de639 > ptp4l[3709.401]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > ptp4l[3710.039]: recvmsg tx timestamp failed: Resource temporarily > unavailable > ptp4l[3710.039]: port 1: send delay request failed > ptp4l[3710.039]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED > ptp4l[3725.690]: port 1: FAULTY to LISTENING on FAULT_CLEARED > ptp4l[3726.698]: port 1: new foreign master ece555.fffe.2de639-2 > ptp4l[3731.022]: selected best master clock ece555.fffe.2de639 > ptp4l[3731.022]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > ptp4l[3731.193]: recvmsg tx timestamp failed: Resource temporarily > unavailable > ptp4l[3731.193]: port 1: send delay request failed > ptp4l[3731.193]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED > > Software timestamping: > > # ptp4l -i p16p1 -p /dev/ptp0 -m -2 -S > > ptp4l[3826.218]: port 1: INITIALIZING to LISTENING on INITIALIZE > ptp4l[3826.218]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[3828.312]: port 1: new foreign master ece555.fffe.2de639-2 > ptp4l[3832.218]: port 1: LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > ptp4l[3832.636]: selected best master clock ece555.fffe.2de639 > ptp4l[3832.636]: port 1: MASTER to UNCALIBRATED on RS_SLAVE > ptp4l[3833.805]: negative path delay -3374260 > ptp4l[3833.805]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[3833.805]: t2 - t3 = -87573969 > ptp4l[3833.805]: t4 - t1 = +80825448 > ptp4l[3833.805]: c1 0 > ptp4l[3833.805]: c2 0 > ptp4l[3833.805]: c3 0 > ptp4l[3833.805]: port 1: minimum delay request interval 2^3 > ptp4l[3834.628]: negative path delay -35159469 > ptp4l[3834.628]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[3834.628]: t2 - t3 = -910670474 > ptp4l[3834.628]: t4 - t1 = +840351536 > ptp4l[3834.628]: c1 0 > ptp4l[3834.628]: c2 0 > ptp4l[3834.628]: c3 0 > ptp4l[3834.798]: master offset -10774702751233 s0 adj +0 path delay > -19266864 > ptp4l[3835.879]: master offset -10774619261329 s0 adj +0 path delay > -19266864 > > > What is the difference between hardware and software timestamping in > this case? > Why Hardware timestamping is not working properly? > Why software timestamping shows the correct time values, but does not > synchronize time with hardware ptp clock (/dev/ptp0)? > > Sincerely, Alexander. > > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ost > g.clktrk > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Richard C. <ric...@gm...> - 2013-08-01 17:58:39
|
On Thu, Aug 01, 2013 at 05:44:37PM +0000, Keller, Jacob E wrote: > > I encountered a problem while obtaining the time from the adapter Intel > > pro1000 (82576). ... > > ptp4l[3704.267]: selected /dev/ptp0 as PTP clock > > ptp4l[3704.278]: port 1: INITIALIZING to LISTENING on INITIALIZE > > ptp4l[3704.278]: port 0: INITIALIZING to LISTENING on INITIALIZE > > ptp4l[3705.077]: port 1: new foreign master ece555.fffe.2de639-2 > > ptp4l[3709.401]: selected best master clock ece555.fffe.2de639 > > ptp4l[3709.401]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > > ptp4l[3710.039]: recvmsg tx timestamp failed: Resource temporarily > > unavailable > > This means your tx timestamp is not being properly detected. I don't > know for sure why this is, but there are a few reasons. I will > forward this to the intel engineer who designed the driver for this > part. I wrote the original igb ptp code, but I never tested the 82576 because I don't have one. I am not sure if Intel tested this either. How about just increasing the tx_timestamp_timeout configuration option to 100 or 1000? Thanks, Richard |
|
From: Keller, J. E <jac...@in...> - 2013-08-01 20:54:35
|
On Thu, 2013-08-01 at 19:58 +0200, Richard Cochran wrote: > On Thu, Aug 01, 2013 at 05:44:37PM +0000, Keller, Jacob E wrote: > > > > I encountered a problem while obtaining the time from the adapter Intel > > > pro1000 (82576). > > ... > > > > ptp4l[3704.267]: selected /dev/ptp0 as PTP clock > > > ptp4l[3704.278]: port 1: INITIALIZING to LISTENING on INITIALIZE > > > ptp4l[3704.278]: port 0: INITIALIZING to LISTENING on INITIALIZE > > > ptp4l[3705.077]: port 1: new foreign master ece555.fffe.2de639-2 > > > ptp4l[3709.401]: selected best master clock ece555.fffe.2de639 > > > ptp4l[3709.401]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > > > ptp4l[3710.039]: recvmsg tx timestamp failed: Resource temporarily > > > unavailable > > > > This means your tx timestamp is not being properly detected. I don't > > know for sure why this is, but there are a few reasons. I will > > forward this to the intel engineer who designed the driver for this > > part. > > I wrote the original igb ptp code, but I never tested the 82576 > because I don't have one. I am not sure if Intel tested this either. > > How about just increasing the tx_timestamp_timeout configuration > option to 100 or 1000? > > Thanks, > Richard I believe this is actually physical hardware dropping the timestamps, not an issue of not returning them fast enough. I know that Matthew Vick has done some testing of the 82576 but not that much. I also believe the use of poll has since removed any of the issues due to timing (we poll for an entire second if it isn't there!) You could try increasing the poll time just in case to see if it helps.. Basically, the 82576 is not a very reliable part for timestamping... - Jake |
×
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