Below is my PTP configuration. It doesn't run in 'pure' software timestamping, i.e. although ptp4l is configured for software timestamping, the packet timestamps are provided by the FPGA hardware on a NIC, which gets the host system time every 1 second and steps/slews to it. There may be a synchronization issue between the system clock that is maintained by ptp4l and the FPGA based hardware clock. I am guessing that the large offsets are due to wrong timestamps and not sure how best to debug it...
In 2.6.35 kernel, clock_adjtime() is defined as adjtimex() by #ifndef HAVE_CLOCK_ADJTIME, and in 3.18.12 clock_adjtime() is used as is, but that seems not to be the issue. Thanks. / #cat /etc/ptp4l.conf [global] domainNumber 0 slaveOnly 1 priority1 128 priority2 128 clockClass 248 clockAccuracy 254 offsetScaledLogVariance 65535 freq_est_interval 1 time_stamping software tx_timestamp_timeout 1 logging_level 6 verbose 1 use_syslog 0 summary_interval 0 [eth1] delay_mechanism E2E network_transport UDPv4 delayAsymmetry 0 logAnnounceInterval 1 logSyncInterval 0 logMinDelayReqInterval 0 logMinPdelayReqInterval 0 announceReceiptTimeout 3 syncReceiptTimeout 0 delay_filter moving_average delay_filter_length 10 path_trace_enabled 0 fault_reset_interval 4 -----Original Message----- From: Keller, Jacob E [mailto:[email protected]] Sent: Friday, January 15, 2016 1:28 PM To: Daniel Le <[email protected]>; [email protected] Subject: Re: [Linuxptp-users] Master offsets don't converge On Fri, 2016-01-15 at 16:19 +0000, Daniel Le wrote: > Hello, > > My ptp4l version 1.4 in software timestamping mode works fine with a > Linux kernel 2.6.35, however when I switch to the kernel 3.18.12 (and > new Ethernet driver), I see the master offsets are huge and never > converge. Any pointer to debug this is much appreciated. > You say this is software timestamping? What's your configuration? I would suspect such a large kernel change to possibly be result of a driver bug, but this wouldn't be the case if you're using pure software timestamping. Can you copy your ptp4l.conf file? Are you using only unmodified upstream versions? If you're using any modifications, I would bisect through those, confirming that the vanilla versions work just fine. Regards, Jake > / #ptp4l -f /etc/ptp4l.conf > ptp4l[250704.924]: port 1: INITIALIZING to LISTENING on INITIALIZE > ptp4l[250704.924]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[250705.355]: port 1: new foreign master 00b0ae.fffe.02d103-1 > ptp4l[250708.955]: selected best master clock 00b0ae.fffe.02d103 > ptp4l[250708.955]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > ptp4l[250709.856]: port 1: minimum delay request interval 2^-7 > ptp4l[250710.698]: master offset1 -6601404463576 s0 freq +100000000 > path delay 220834 > ptp4l[250711.598]: master offset1 -6601404940762 s0 freq +100000000 > path delay 224676 > ptp4l[250712.498]: master offset1 -6601405412898 s0 freq +100000000 > path delay 223500 This smells of a driver bug. Notice how the frequency shift is maxed, and yet the clock is still drifting farther apart. This either means that the real clock drift is *over* 10%, (which is very unlikely), or there is a bug in the frequency tuning. But if you really are using software timestamps, this doesn't make sense. Again, if you're not using vanilla LinuxPTP 1.4, I would retry with that and confirm the behavior. If you are using vanilla LinuxPTP, I would confirm that you are infact actually using software only timestamping. Regards, Jake ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Linuxptp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-users
