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

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

Hi Jake, 

Because my hardware NIC is not 1588 capable and that would require FPGA change, however I'm hoping to get better timestamp accuracy from the hardware clock that is tuned to the host system clock in software timestamping mode (which I understand it's in the reverse direction of LinuxPTP hardware timestamping configuration where the system clock synchronizes to the PHC clock instead).

Daniel

-----Original Message-----
From: Keller, Jacob E [mailto:jac...@in...] 
Sent: Friday, January 15, 2016 2:29 PM
To: Daniel Le <dan...@ex...>; lin...@li...
Subject: Re: [Linuxptp-users] Master offsets don't converge

It is almost certainly a result of the driver doing the mixed hardware/software timestamps.

I suspect that the software clock is being slewed, but somehow your timestamps are not being updated fast enough so these hardware timestamps are no longer matching against the system clock.

Out of curiosity, why not expose the hardware clock directly as a PHC?

Regards,
Jake

On Fri, 2016-01-15 at 18:56 +0000, Daniel Le wrote:
> 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...urceforge.
> net
> 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