Re: [Linuxptp-users] Master offsets don't converge

[Daniel Le <dan...@ex...>]

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:jac...@in...] 
Sent: Friday, January 15, 2016 1:28 PM
To: Daniel Le <dan...@ex...>; lin...@li...
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