Hello Harold, On Thu, 2015-08-13 at 20:29 +0000, Harold Lapprich wrote: > To Whom It May Concern, > > Continue to test phc2sys and it does some strange things at times > (configuration is where the system clock is a slave to the slave > ptp4l on the same system: phc2sys -a -r -m, ptp4l -i eth0 -s -m). > > For some reason phc2sys jumps to the rail when ptp4l (running on the > same system) doesn't move hardly any (have attached screen text for > review). Does anyone have any idea why phc2sys is seeing 'clockcheck: > clock jumped forward or running greater than expected!' issue? >
ptp4l controls a hardware clock. Unlikely anything else is interferring with this. phc2sys is set to control CLOCK_REALTIME by tuning it to frequency of the device hardware clock. In this mode, many other possible programs might be changing the clock. For example, ntpd, chronyd, or some other NTP application. The most likely issue is that you have a time manager like ntpd or some other NTP client running on the system. > > Possible Solution: > > To prevent quick changes in the PTP clock's frequency or from > thinking that there has been a quick change, the synchronization to > the system clock can be loosened by using smaller P (proportional) > and I (integral) constants of the PI servo (this maybe something to > do in order to avoid the phc2sys error that I am trying to post). > The error you are seeing will happen regardless. It is caught when some other process jumps the clock (ie: phc2sys did not expect it to happen). Most likely the result of ntpd or similar. > > Thanks, > Harold Lapprich > > PS. Screen text for ptp4l -i eth0 -m and phc2sys -a -r -m follow > (along with the error text): > > Thanks. Comments below. > > > root@zx3-pm3-zynq7:~# ptp4l -i eth0 -s -m > ptp4l[81321.709]: selected /dev/ptp0 as PTP clock > ptp4l[81321.713]: driver changed our HWTSTAMP options > ptp4l[81321.713]: tx_type 1 not 1 > ptp4l[81321.714]: rx_filter 1 not 12 > ptp4l[81321.714]: port 1: INITIALIZING to LISTENING on INITIALIZE > ptp4l[81321.714]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[81322.388]: port 1: new foreign master 000a35.fffe.01225c-1 > ptp4l[81325.988]: selected best master clock 000a35.fffe.01225c > ptp4l[81325.988]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > ptp4l[81328.688]: master offset 64344882363235 s0 freq -96829 path > delay 12 > 773 > ptp4l[81329.588]: master offset 64344882354480 s1 freq -105583 path > delay 12 > 773 > ptp4l[81330.488]: master offset 391 s2 freq -105192 path delay > 12773 > ptp4l[81330.488]: port 1: UNCALIBRATED to SLAVE on > MASTER_CLOCK_SELECTED > ptp4l[81331.388]: master offset 508 s2 freq -104958 path delay > 12773 > ptp4l[81332.288]: master offset 1231 s2 freq -104083 path delay > 12773 > ptp4l[81333.188]: master offset 562 s2 freq -104382 path delay > 11020 > ptp4l[81334.088]: master offset -1134 s2 freq -105910 path delay > 11198 > ptp4l[81334.988]: master offset -1380 s2 freq -106496 path delay > 11198 > ptp4l[81335.888]: master offset -841 s2 freq -106371 path delay > 11020 > ptp4l[81336.788]: master offset -1036 s2 freq -106818 path delay > 11019 > ptp4l[81337.742]: master offset -1283 s2 freq -107376 path delay > 11019 > ptp4l[81338.743]: master offset -328 s2 freq -106806 path delay > 10965 > ptp4l[81339.743]: master offset -340 s2 freq -106916 path delay > 10965 <snip> > login as: root > Last login: Mon Aug 10 15:27:55 2015 from 192.168.1.164 > root@zx3-pm3-zynq7:~# phc2sys -a -r -m > phc2sys[81336.197]: reconfiguring after port state change > phc2sys[81336.198]: selecting CLOCK_REALTIME for synchronization > phc2sys[81336.198]: selecting eth0 as the master clock > phc2sys[81336.198]: phc offset 2329760226185187 s0 freq +100000000 > delay 2439 > phc2sys[81337.199]: phc offset 2329760114861905 s1 freq -106524 delay Ok, see here how your phc offset is set really large? Basically, we jump the clock at start to correct this. Most likely your ptp4l is being served something other than the time domain you expect. > 2403 > phc2sys[81338.201]: phc offset -1007908 s2 freq -1114432 delay > 2701 > phc2sys[81339.202]: phc offset -6107 s2 freq -415004 delay 2736 > phc2sys[81340.202]: phc offset 307598 s2 freq -103131 delay 2668 <snip> I cut out a bunch of stuff here we jump to the interesting part. > phc2sys[81808.422]: phc offset -721 s2 freq -105227 delay 2688 > phc2sys[81809.422]: phc offset 7 s2 freq -104715 delay 2665 > phc2sys[81810.423]: phc offset -92 s2 freq -104812 delay 2683 > phc2sys[81811.423]: phc offset -736 s2 freq -105484 delay 2664 > phc2sys[81812.424]: clockcheck: clock jumped forward or running > faster than expected! > phc2sys[81812.424]: phc offset 2336539574238124 s0 freq -105484 delay > 2664 > phc2sys[81813.424]: phc offset 2336539574237736 s2 freq -105356 delay > 2670 Suddenly, your clock is now *reset* to the old time offset. I suspect some time manager such as ntpd is doing this but I can't know for sure. Then, since it's not initial launch, phc2sys (by default) will not jump the clock again so it tries to slew the frequency until it gets back in line. With an offset this large that is basically not possible. I would look for if your system is running ntpd, chrondy, timesyncd or similar to control the clock as well. You really can't have multiple things doing this. Regards, Jake ------------------------------------------------------------------------------ _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
