Thread: [Linuxptp-users] Randomly time jumps of ptp clock device
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
From: Thomas M. <tm....@gm...> - 2014-02-26 12:07:34
|
Hi everybody, for a little project at our company I try to sync the system clocks of two devices. Both devices use a Intel 82574L network interface. On the PTP-master phc2sys is used to sync CLOCK_REALTIME to /dev/ptp0. On the PTP-slave phy2sys is used to sync /dev/ptp0 to CLOCK_REALTIME. Linux Kernel v3.12.2 is used. Basically the whole sync process seems to work, but from time to time the /dev/ptp0 device do a big time jump (sometimes on master, sometimes on slave). Log output of the PTP slave: /var/src/linuxptp # ./ptp4l -i eth0 -m -l6 -s ptp4l[67389.205]: selected /dev/ptp0 as PTP clock ptp4l[67389.208]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[67389.209]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[67394.495]: port 1: new foreign master 0013ab.fffe.004874-1 ptp4l[67396.079]: selected best master clock 0013ab.fffe.003ea2 ptp4l[67398.596]: selected best master clock 0013ab.fffe.004874 ptp4l[67398.596]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[67400.596]: master offset 692552075142917737 s0 freq +44869 path delay -3816 ptp4l[67401.596]: master offset 692552075142969782 s1 freq +96896 path delay -10659 ptp4l[67402.596]: master offset -47285 s2 freq +49611 path delay -10659 ptp4l[67402.596]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[67403.597]: master offset -56417 s2 freq +26293 path delay -10659 ptp4l[67404.597]: master offset -45713 s2 freq +20072 path delay -4808 ptp4l[67405.599]: master offset -21317 s2 freq +30754 path delay -4808 ptp4l[67406.597]: master offset -6970 s2 freq +38706 path delay -3816 ptp4l[67407.597]: master offset -961 s2 freq +42624 path delay -2878 ptp4l[67408.686]: master offset 245 s2 freq +43542 path delay -1401 ... ptp4l[67877.698]: master offset -109 s2 freq +44802 path delay 728 ptp4l[67878.698]: master offset -29 s2 freq +44850 path delay 728 ptp4l[67879.611]: clockcheck: clock jumped forward or running faster than expected! ptp4l[67879.721]: master offset 70368744177690 s0 freq +44850 path delay 725 ptp4l[67879.722]: port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT ptp4l[67880.822]: master offset 70368744177750 s1 freq +44930 path delay 720 ptp4l[67881.840]: master offset -5688 s2 freq +39242 path delay 720 ptp4l[67881.840]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[67882.748]: master offset -584 s2 freq +42640 path delay 712 ptp4l[67883.690]: master offset 2016 s2 freq +45064 path delay 702 ptp4l[67884.679]: master offset 2126 s2 freq +45779 path delay 695 ... I tried a few things to locate the reason for this behavior, and find out it's possible to decrease the time between this time jumps dramatically by do a lot of clk_getime() calls on the ptp device. For this test a modified the kernel testptp tool to read the time in a loop. Log output: /var/src # ./testptp -d /dev/ptp0 -g readCount=1; clock time: 1394816657.943618751 or Fri Mar 14 17:04:17 2014 readCount=2; clock time: 1394816657.944179005 or Fri Mar 14 17:04:17 2014 ... readCount=41985; clock time: 1394816661.206155491 or Fri Mar 14 17:04:21 2014 readCount=41986; clock time: 1394816661.206209448 or Fri Mar 14 17:04:21 2014 readCount=41987; clock time: 1394887029.949932637 or Sat Mar 15 12:37:09 2014 readCount=41988; clock time: 1394887029.950497306 or Sat Mar 15 12:37:09 2014 ... readCount=73430; clock time: 1394887032.177426719 or Sat Mar 15 12:37:12 2014 readCount=73431; clock time: 1394887032.177519354 or Sat Mar 15 12:37:12 2014 readCount=73432; clock time: 1394957400.921267022 or Sun Mar 16 08:10:00 2014 readCount=73433; clock time: 1394957400.921897480 or Sun Mar 16 08:10:00 2014 ... I guess this big time jumps are not normal, so do anybody know how I can fix this problem? Regards, Thomas |
From: Richard C. <ric...@gm...> - 2014-02-26 12:26:24
|
On Wed, Feb 26, 2014 at 01:07:25PM +0100, Thomas Mayer wrote: > Hi everybody, > for a little project at our company I try to sync the system clocks of > two devices. Both devices use a Intel 82574L network interface. On the ... > I guess this big time jumps are not normal, so do anybody know how I can > fix this problem? There appears to be hardware bug with the 82574L. See the thread starting with: http://article.gmane.org/gmane.comp.linux.ptp.user/665 Sorry, Richard |
From: Thomas M. <tm....@gm...> - 2014-02-26 13:04:35
|
Thanks for your very fast help! Good to know it's not my fault :D According to this mail "http://article.gmane.org/gmane.comp.linux.ptp.user/676/match=82574l" I can hope for a fix :) Regards, Thomas On 26.02.2014 13:25, Richard Cochran wrote: > On Wed, Feb 26, 2014 at 01:07:25PM +0100, Thomas Mayer wrote: >> Hi everybody, >> for a little project at our company I try to sync the system clocks of >> two devices. Both devices use a Intel 82574L network interface. On the > > ... > >> I guess this big time jumps are not normal, so do anybody know how I can >> fix this problem? > > There appears to be hardware bug with the 82574L. See the thread starting with: > > http://article.gmane.org/gmane.comp.linux.ptp.user/665 > > Sorry, > Richard > |
From: Vick, M. <mat...@in...> - 2014-02-26 16:51:58
|
On 2/26/14, 5:04 AM, "Thomas Mayer" <tm....@gm...> wrote: >Thanks for your very fast help! >Good to know it's not my fault :D >According to this mail >"http://article.gmane.org/gmane.comp.linux.ptp.user/676/match=82574l" I >can hope for a fix :) > >Regards, >Thomas Thomas, We have posted a new version of e1000e to our SourceForge website (http://sourceforge.net/projects/e1000/) for our out-of-tree driver for 82574L that contains our proposed fix for this issue. Please give this a try and let us know if it resolves the weirdness you're seeing. We're still working on the upstream equivalent for this patch. Cheers, Matthew Matthew Vick Linux Development Networking Division Intel Corporation |
From: Vick, M. <mat...@in...> - 2014-02-26 16:54:08
|
On 2/26/14, 8:51 AM, "Vick, Matthew" <mat...@in...> wrote: >On 2/26/14, 5:04 AM, "Thomas Mayer" <tm....@gm...> wrote: > >>Thanks for your very fast help! >>Good to know it's not my fault :D >>According to this mail >>"http://article.gmane.org/gmane.comp.linux.ptp.user/676/match=82574l" I >>can hope for a fix :) >> >>Regards, >>Thomas > >Thomas, > >We have posted a new version of e1000e to our SourceForge website >(http://sourceforge.net/projects/e1000/) for our out-of-tree driver for >82574L that contains our proposed fix for this issue. Please give this a >try and let us know if it resolves the weirdness you're seeing. We're >still working on the upstream equivalent for this patch. > >Cheers, >Matthew > >Matthew Vick >Linux Development >Networking Division >Intel Corporation Sorry for the double response, but I just realized I left out the version number you'll need (just in case): 3.0.4, which is the most recent version at the time of this e-mail. Cheers, Matthew |
From: Thomas M. <tm....@gm...> - 2014-02-27 14:03:57
|
On 26.02.2014 17:53, Vick, Matthew wrote: > On 2/26/14, 8:51 AM, "Vick, Matthew" <mat...@in...> wrote: > >> On 2/26/14, 5:04 AM, "Thomas Mayer" <tm....@gm...> wrote: >> >>> Thanks for your very fast help! >>> Good to know it's not my fault :D >>> According to this mail >>> "http://article.gmane.org/gmane.comp.linux.ptp.user/676/match=82574l" I >>> can hope for a fix :) >>> >>> Regards, >>> Thomas >> >> Thomas, >> >> We have posted a new version of e1000e to our SourceForge website >> (http://sourceforge.net/projects/e1000/) for our out-of-tree driver for >> 82574L that contains our proposed fix for this issue. Please give this a >> try and let us know if it resolves the weirdness you're seeing. We're >> still working on the upstream equivalent for this patch. >> >> Cheers, >> Matthew >> >> Matthew Vick >> Linux Development >> Networking Division >> Intel Corporation > > Sorry for the double response, but I just realized I left out the version > number you'll need (just in case): 3.0.4, which is the most recent version > at the time of this e-mail. > > Cheers, > Matthew > > Hi Matthew, first short test looks good :) I will start a long test over the weekend and let you know if something goes wrong. Regards, Thomas |
From: Vick, M. <mat...@in...> - 2014-02-27 15:37:45
|
On 2/27/14, 6:03 AM, "Thomas Mayer" <tm....@gm...> wrote: >On 26.02.2014 17:53, Vick, Matthew wrote: >> On 2/26/14, 8:51 AM, "Vick, Matthew" <mat...@in...> wrote: >> >>> On 2/26/14, 5:04 AM, "Thomas Mayer" <tm....@gm...> wrote: >>> >>>> Thanks for your very fast help! >>>> Good to know it's not my fault :D >>>> According to this mail >>>> "http://article.gmane.org/gmane.comp.linux.ptp.user/676/match=82574l" >>>>I >>>> can hope for a fix :) >>>> >>>> Regards, >>>> Thomas >>> >>> Thomas, >>> >>> We have posted a new version of e1000e to our SourceForge website >>> (http://sourceforge.net/projects/e1000/) for our out-of-tree driver for >>> 82574L that contains our proposed fix for this issue. Please give this >>>a >>> try and let us know if it resolves the weirdness you're seeing. We're >>> still working on the upstream equivalent for this patch. >>> >>> Cheers, >>> Matthew >>> >>> Matthew Vick >>> Linux Development >>> Networking Division >>> Intel Corporation >> >> Sorry for the double response, but I just realized I left out the >>version >> number you'll need (just in case): 3.0.4, which is the most recent >>version >> at the time of this e-mail. >> >> Cheers, >> Matthew >> >> > >Hi Matthew, > >first short test looks good :) >I will start a long test over the weekend and let you know if something >goes wrong. > >Regards, >Thomas Happy to hear it! :) I look forward to the results of your weekend test. Cheers, Matthew |
From: Thomas M. <tm....@gm...> - 2014-03-03 08:25:28
|
On 27.02.2014 16:37, Vick, Matthew wrote: > On 2/27/14, 6:03 AM, "Thomas Mayer" <tm....@gm...> wrote: > >> On 26.02.2014 17:53, Vick, Matthew wrote: >>> On 2/26/14, 8:51 AM, "Vick, Matthew" <mat...@in...> wrote: >>> >>>> On 2/26/14, 5:04 AM, "Thomas Mayer" <tm....@gm...> wrote: >>>> >>>>> Thanks for your very fast help! >>>>> Good to know it's not my fault :D >>>>> According to this mail >>>>> "http://article.gmane.org/gmane.comp.linux.ptp.user/676/match=82574l" >>>>> I >>>>> can hope for a fix :) >>>>> >>>>> Regards, >>>>> Thomas >>>> >>>> Thomas, >>>> >>>> We have posted a new version of e1000e to our SourceForge website >>>> (http://sourceforge.net/projects/e1000/) for our out-of-tree driver for >>>> 82574L that contains our proposed fix for this issue. Please give this >>>> a >>>> try and let us know if it resolves the weirdness you're seeing. We're >>>> still working on the upstream equivalent for this patch. >>>> >>>> Cheers, >>>> Matthew >>>> >>>> Matthew Vick >>>> Linux Development >>>> Networking Division >>>> Intel Corporation >>> >>> Sorry for the double response, but I just realized I left out the >>> version >>> number you'll need (just in case): 3.0.4, which is the most recent >>> version >>> at the time of this e-mail. >>> >>> Cheers, >>> Matthew >>> >>> >> >> Hi Matthew, >> >> first short test looks good :) >> I will start a long test over the weekend and let you know if something >> goes wrong. >> >> Regards, >> Thomas > > Happy to hear it! :) > > I look forward to the results of your weekend test. > > Cheers, > Matthew > > Hi Matthew, tested with 2 devices and ptp4l + phc2sys for about 89 hours without problems :) ...I would say this bug is fixed ;) Regards, Thomas |
From: Vick, M. <mat...@in...> - 2014-03-03 16:38:05
|
On 3/3/14, 12:25 AM, "Thomas Mayer" <tm....@gm...> wrote: >On 27.02.2014 16:37, Vick, Matthew wrote: >> On 2/27/14, 6:03 AM, "Thomas Mayer" <tm....@gm...> wrote: >> >>> On 26.02.2014 17:53, Vick, Matthew wrote: >>>> On 2/26/14, 8:51 AM, "Vick, Matthew" <mat...@in...> wrote: >>>> >>>>> On 2/26/14, 5:04 AM, "Thomas Mayer" <tm....@gm...> wrote: >>>>> >>>>>> Thanks for your very fast help! >>>>>> Good to know it's not my fault :D >>>>>> According to this mail >>>>>> >>>>>>"http://article.gmane.org/gmane.comp.linux.ptp.user/676/match=82574l" >>>>>> I >>>>>> can hope for a fix :) >>>>>> >>>>>> Regards, >>>>>> Thomas >>>>> >>>>> Thomas, >>>>> >>>>> We have posted a new version of e1000e to our SourceForge website >>>>> (http://sourceforge.net/projects/e1000/) for our out-of-tree driver >>>>>for >>>>> 82574L that contains our proposed fix for this issue. Please give >>>>>this >>>>> a >>>>> try and let us know if it resolves the weirdness you're seeing. We're >>>>> still working on the upstream equivalent for this patch. >>>>> >>>>> Cheers, >>>>> Matthew >>>>> >>>>> Matthew Vick >>>>> Linux Development >>>>> Networking Division >>>>> Intel Corporation >>>> >>>> Sorry for the double response, but I just realized I left out the >>>> version >>>> number you'll need (just in case): 3.0.4, which is the most recent >>>> version >>>> at the time of this e-mail. >>>> >>>> Cheers, >>>> Matthew >>>> >>>> >>> >>> Hi Matthew, >>> >>> first short test looks good :) >>> I will start a long test over the weekend and let you know if something >>> goes wrong. >>> >>> Regards, >>> Thomas >> >> Happy to hear it! :) >> >> I look forward to the results of your weekend test. >> >> Cheers, >> Matthew >> >> >Hi Matthew, > >tested with 2 devices and ptp4l + phc2sys for about 89 hours without >problems :) ...I would say this bug is fixed ;) > >Regards, >Thomas Thomas, Excellent! I'll feed information back into the team internally and we'll continue to work on the upstream patch. Thank you for testing out this fix! Cheers, Matthew |