linuxptp-users — Open discussion on using the linuxptp software.

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

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

[Keller, J. E <jac...@in...>]

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

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

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

[Keller, J. E <jac...@in...>]

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

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

[Richard C. <ric...@gm...>]

On Fri, Jan 15, 2016 at 04:19:23PM +0000, Daniel Le wrote:
> 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.

1. Start with vanilla 1.4 and verfiy correct operation.
2. Add your first (next) minimal change.
3. Correct operation? If yes, goto step 2
4. You found the bug.

If you have lots of changes, then use git bisect.

HTH,
Richard

[Linuxptp-users] Master offsets don't converge

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

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.

/ #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
ptp4l[250713.398]: master offset1 -6601405890510 s0 freq +100000000 path delay    227796
ptp4l[250714.298]: master offset1 -6601406361480 s0 freq +100000000 path delay    225458
ptp4l[250715.198]: master offset1 -6601406835542 s0 freq +100000000 path delay    226236
ptp4l[250716.098]: master offset1 -6601407311244 s0 freq +100000000 path delay    228594
ptp4l[250716.998]: master offset1 -6601407784176 s0 freq +100000000 path delay    228218
ptp4l[250717.898]: master offset1 -6601408255930 s0 freq +100000000 path delay    226660
ptp4l[250718.798]: master offset1 -6601408732050 s0 freq +100000000 path delay    229468
ptp4l[250719.698]: master offset1 -6601409205854 s0 freq +100000000 path delay    229956
ptp4l[250720.598]: master offset1 -6601409673392 s0 freq +100000000 path delay    224186
ptp4l[250721.497]: master offset1 -6601410151822 s0 freq +100000000 path delay    229300
ptp4l[250722.397]: master offset1 -6601410625760 s0 freq +100000000 path delay    229898
ptp4l[250723.297]: master offset1 -6601411100194 s0 freq +100000000 path delay    231052
ptp4l[250724.197]: master offset1 -6601411564234 s0 freq +100000000 path delay    221780
ptp4l[250725.097]: master offset1 -6601412044146 s1 freq +99573391 path delay    228348
ptp4l[250725.208]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[250725.319]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[250725.426]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[250725.536]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[250725.638]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[250725.741]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[250725.853]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[250725.965]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[250725.998]: master offset1 -2711305334 s0 freq +99573391 path delay    228348
ptp4l[250726.068]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[250726.176]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[250726.280]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[250726.387]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[250726.491]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[250726.605]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[250726.713]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[250726.814]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[250726.898]: master offset1 -2711772472 s0 freq +99573391 path delay    222142
ptp4l[250726.916]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[250727.020]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[250727.120]: clockcheck: clock jumped forward or running faster than expected!

Thanks,
Daniel

Re: [Linuxptp-users] Want to reduce offset (which is distance dependant) between boundary clocks.

[Richard C. <ric...@gm...>]

On Fri, Jan 15, 2016 at 03:51:57PM +0530, aniket wrote:
> In my first experiment,  master and slave are 2 Km away from each other. 
> In this case I got offset at slave PHY clock around 50 nano second.
> 
> In second experiment I relocate my slave around 20 Km from master where 
> I got offset of 150 nano seconds.

So you are checking against GPS, right?

> Ideally the offset between PHY clocks should remain constant though we 
> are varying distance between them (correct me if I am wrong).

If the system is properly calibrated, then the offset should be
minimal, and the difference in distance should be reflected in the
path delay.

> Do we need to specify any parameter (which is distance dependant) while 
> issuing above command? Because there are many PROGRAM AND CLOCK OPTIONS 
> in ptp4l. Do we need to set any specific option?

We do have options to calibrate the system:

 delayAsymmetry - corrects for any asymmetry between the Rx and Tx paths
 egressLatency  - corrects the transmit latency at the MAC/PHY
 ingressLatency - corrects the receive latency at the MAC/PHY

What you observe sounds like an asymmetry.  If it is, then it is
surprising to me that the asymmetry grows with distance.  Then again,
I don't know anything about your equipment, and so maybe this is
simply a property of your fibre optic links.

HTH,
Richard





 

[Linuxptp-users] Want to reduce offset (which is distance dependant) between boundary clocks.

[aniket <an...@gm...>]

Hi...very good afternoon to all.

Myself Aniket Hendre, project engineer C from National Centre for Radio 
Astrophysics, India.

I am synchronising two boundary clocks using ptp4l. I found that the 
offset at the slave PHY clock from master PHY clock varies with respect 
to distance between these clocks.

In my first experiment,  master and slave are 2 Km away from each other. 
In this case I got offset at slave PHY clock around 50 nano second.

In second experiment I relocate my slave around 20 Km from master where 
I got offset of 150 nano seconds.
 
Ideally the offset between PHY clocks should remain constant though we 
are varying distance between them (correct me if I am wrong).

For both experiments mentioned above I am issuing following common 
command 
ptp4l -i eth1 -m. I have connected these two machine using fibre optic 
cable with media converter on both ends. My both ethernet ports are 
supporting IEEE1588.

Do we need to specify any parameter (which is distance dependant) while 
issuing above command? Because there are many PROGRAM AND CLOCK OPTIONS 
in ptp4l. Do we need to set any specific option?

Please help.

Thanks in advance
Aniket Hendre

Re: [Linuxptp-users] Patch for incdefs.sh

[Richard C. <ric...@gm...>]

On Thu, Dec 24, 2015 at 07:46:45AM -0500, Chris LaRocque wrote:
> While working with buildroot, cross-compiling linuxptp for ARM I ran into;

Thanks for posting this fix.

> - files=$(find $d -type f -name time.h)
> + files=$(find $d -regextype posix-egrep -regex ".*/time.*.h")

I would prefer this instead:

	files=$(find $d -type f -name time.h -o -name timex.h)

Can you see if that works for your uClinux setup as well?

Thanks,
Richard

[Linuxptp-users] Patch for incdefs.sh

[Chris L. <cl...@gm...>]

Hello

While working with buildroot, cross-compiling linuxptp for ARM I ran into;

In file included from clock.c:33:0:
missing.h:66:19: error: static declaration of ‘clock_adjtime’ follows
non-static declaration
 static inline int clock_adjtime(clockid_t id, struct timex *tx)
                   ^
In file included from missing.h:28:0,
                 from clock.c:33:
~/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabihf/sysroot/usr/include/sys/timex.h:128:12:
note: previous declaration of ‘clock_adjtime’ was here
 extern int clock_adjtime (clockid_t __clock_id, struct timex *__ntx)
__THROW;
            ^
make: *** [clock.o] Error 1

;even though uclibc 1.0.9 incorporates the feature. It is defined in
timex.h which is not found using the stock file.

-----------------------------------------------------------------------------------
--- a./incdefs.sh 2015-12-18 13:33:24.853244045 -0500
+++ b./incdefs.sh 2015-12-18 13:34:52.570367632 -0500
@@ -27,7 +27,7 @@
  # Get list of directories searched for header files.
  dirs=$(echo "" | ${CROSS_COMPILE}cpp -Wp,-v 2>&1 >/dev/null # Look for
clock_adjtime().
  for d in $dirs; do
- files=$(find $d -type f -name time.h)
+ files=$(find $d -regextype posix-egrep -regex ".*/time.*.h")
  for f in $files; do
  if grep -q clock_adjtime $f; then
  printf " -DHAVE_CLOCK_ADJTIME"

-----------------------------------------------------------------------------------------

Regards

Chris LaRocque

Re: [Linuxptp-users] ptp4l and network connectivity interruption

[Richard C. <ric...@gm...>]

On Sat, Dec 12, 2015 at 03:58:31PM -0500, Brian Walsh wrote:
> I was not sure if having it reset during ifup makes more sense. Does the
> clock go away when the interface is down? I can't test that right now.
> It is my primary interface so it is always up on my device.

The /dev/ptpX persists from ptp_clock_register() until
ptp_clock_unregister().  Ideally, the clock should appear when the
device is probed and stay running until either the HW is unplugged or
the driver gets unloaded.

There are some HW designs out there that cause the clock to go away or
become unusable when the link state changes, but I think the 82574
does not have those kinds of issues.
 
> Makes sense. Stop reseting the clock and it will not reset.

Yup.

Thanks,
Richard

Re: [Linuxptp-users] ptp4l and network connectivity interruption

[Brian W. <br...@wa...>]

On Sat, Dec 12, 2015 at 09:50:32PM +0100, Richard Cochran wrote:
> I wouldn't follow ixgbe, because putting the reset in the 'open'
> method means that the clock will become reset during ifup/ifdown.  For
> the ixgbe this is necessary, IIRC, but I wouldn't do it unless you are 
> absolutely by some HW quirk.

I was not sure if having it reset during ifup makes more sense. Does the
clock go away when the interface is down? I can't test that right now.
It is my primary interface so it is always up on my device.

> I would try something like the following untested patch...

Just finished doing an initial test of quickly making the same changes
you sent. Looks like it fixes the problem I was seeing.

Makes sense. Stop reseting the clock and it will not reset.

Brian

Re: [Linuxptp-users] ptp4l and network connectivity interruption

[Richard C. <ric...@gm...>]

On Sat, Dec 12, 2015 at 03:18:01PM -0500, Brian Walsh wrote:
> I see that. Comparing that code to what happens in the ixgbe driver it
> looks like reseting the clock should be part of e1000e_ptp_init. Then
> the e1000e_ptp_init code should be called in the device open function to
> initialize whenever the device is made active. Pull ptp_init out of the
> probe function.

Sorry, I mixed up the Intel cards WRT the unfortunate HW limitation.
The 82574 does not need to reset the clock at link loss, or at least
it doesn't appear to need it.

I wouldn't follow ixgbe, because putting the reset in the 'open'
method means that the clock will become reset during ifup/ifdown.  For
the ixgbe this is necessary, IIRC, but I wouldn't do it unless you are 
absolutely by some HW quirk.

I would try something like the following untested patch...

Thanks,
Richard


diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 0a854a4..1823148 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -3732,16 +3732,6 @@ static int e1000e_config_hwtstamp(struct e1000_adapter *adapter,
 	er32(RXSTMPH);
 	er32(TXSTMPH);
 
-	/* Get and set the System Time Register SYSTIM base frequency */
-	ret_val = e1000e_get_base_timinca(adapter, &regval);
-	if (ret_val)
-		return ret_val;
-	ew32(TIMINCA, regval);
-
-	/* reset the ns time counter */
-	timecounter_init(&adapter->tc, &adapter->cc,
-			 ktime_to_ns(ktime_get_real()));
-
 	return 0;
 }
 
@@ -6980,6 +6970,7 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 	u16 eeprom_data = 0;
 	u16 eeprom_apme_mask = E1000_EEPROM_APME;
 	s32 rval = 0;
+	u32 regval;
 
 	if (ei->flags2 & FLAG2_DISABLE_ASPM_L0S)
 		aspm_disable_flag = PCIE_LINK_STATE_L0S;
@@ -7270,6 +7261,16 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 	/* carrier off reporting is important to ethtool even BEFORE open */
 	netif_carrier_off(netdev);
 
+	/* Get and set the System Time Register SYSTIM base frequency */
+	err = e1000e_get_base_timinca(adapter, &regval);
+	if (err)
+		goto err_register;
+	ew32(TIMINCA, regval);
+
+	/* reset the ns time counter */
+	timecounter_init(&adapter->tc, &adapter->cc,
+			 ktime_to_ns(ktime_get_real()));
+
 	/* init PTP hardware clock */
 	e1000e_ptp_init(adapter);
 

Re: [Linuxptp-users] ptp4l and network connectivity interruption

[Brian W. <br...@wa...>]

On Sat, Dec 12, 2015 at 06:50:45PM +0100, Richard Cochran wrote:
> This is definitely a driver bug.
> 
> Looking at drivers/net/ethernet/intel/e1000e/netdev.c, in the function
> e1000e_config_hwtstamp(), the time is reset whenever time stamping is
> activated.  That doesn't make any sense.
> 
> It looks like the calls to e1000e_get_base_timinca() and
> timecounter_init() are misplaced.  They should go into the probe
> function instead.

I see that. Comparing that code to what happens in the ixgbe driver it
looks like reseting the clock should be part of e1000e_ptp_init. Then
the e1000e_ptp_init code should be called in the device open function to
initialize whenever the device is made active. Pull ptp_init out of the
probe function.

I will see what i can put together to test based off of the ixgbe code.

Brian

Re: [Linuxptp-users] ptp4l and network connectivity interruption

[Richard C. <ric...@gm...>]

On Fri, Dec 11, 2015 at 03:09:56PM -0500, Brian Walsh wrote:
> I was looking at the linuxptp code to see if it could possibly detect the
> condition. It does detect the initial jump when the hardware starts
> receiving packets again. Maybe it could check the jump against the last
> known offset value. Have it wait for a few packets while the device
> settles before trusting that jump if it is close to the offset.

This is definitely a driver bug.

Looking at drivers/net/ethernet/intel/e1000e/netdev.c, in the function
e1000e_config_hwtstamp(), the time is reset whenever time stamping is
activated.  That doesn't make any sense.

It looks like the calls to e1000e_get_base_timinca() and
timecounter_init() are misplaced.  They should go into the probe
function instead.

Thanks,
Richard

Re: [Linuxptp-users] ptp4l and network connectivity interruption

[Brian W. <br...@wa...>]

On Fri, 11 Dec 2015, Richard Cochran wrote:
> > It is an Intel 82574L. 8086:10d3
> 
> Ok, I have that card.  The driver is the e1000e (and not the e1000).
> Can you send me your iptables script so that I can try and reproduce
> the problem?

I am just dropping udp packets on INPUT for ports 319 and 320

iptables -A INPUT -p udp --dport 319 -j DROP
iptables -A INPUT -p udp --dport 320 -j DROP

After a few seconds I just delete those rules.
 
> > Looking again it appears it may be the opposite of what I thought.
> > ptp4l is maintaining the
> > offset value while the hardware clock has switched back to UTC time. I
> > am not seeing
> > anywhere that ptp4l is reseting the offset to 0 during this state.
> 
> Right, it is in the driver or HW.  I remember that card resetting the
> clock after link loss.  I complained about this, but Intel said it was
> as HW limitation, IIRC.
> 
> However, I wouldn't expect this to happen just from the action of the
> firewall.  That sounds more like a driver bug.
> 

I was looking at the linuxptp code to see if it could possibly detect the
condition. It does detect the initial jump when the hardware starts
receiving packets again. Maybe it could check the jump against the last
known offset value. Have it wait for a few packets while the device
settles before trusting that jump if it is close to the offset.

Brian

Re: [Linuxptp-users] ptp4l and network connectivity interruption

[Richard C. <ric...@gm...>]

On Thu, Dec 10, 2015 at 12:06:19PM -0500, Brian Walsh wrote:
> It is an Intel 82574L. 8086:10d3

Ok, I have that card.  The driver is the e1000e (and not the e1000).
Can you send me your iptables script so that I can try and reproduce
the problem?

> Looking again it appears it may be the opposite of what I thought.
> ptp4l is maintaining the
> offset value while the hardware clock has switched back to UTC time. I
> am not seeing
> anywhere that ptp4l is reseting the offset to 0 during this state.

Right, it is in the driver or HW.  I remember that card resetting the
clock after link loss.  I complained about this, but Intel said it was
as HW limitation, IIRC.

However, I wouldn't expect this to happen just from the action of the
firewall.  That sounds more like a driver bug.

Thanks,
Richard

Re: [Linuxptp-users] If linuxptp support ABMC algorithm?

[Richard C. <ric...@gm...>]

On Fri, Dec 04, 2015 at 08:56:30PM +0100, Richard Cochran wrote:
> On Fri, Dec 04, 2015 at 08:27:11PM +0800, Pengfei zhao wrote:
> > Hi,
> > As the title. if current release of linuxptp stack support alternate BMC specified in telecom profile?
> 
> No, it doesn't support the telecom profle.  We do not have unicast
> implemented.

So, it seems there are now *two* telecom profiles.

1. G.8265.1  Precision time protocol telecom profile for
             frequency synchronization

2. G.8275.1  Precision time protocol telecom profile for
             phase/time synchronization with full timing
             support from the network

In #1 unicast is required and multicast is forbidden.
In #2 multicast is required and unicast is forbidden.

(Brilliant)

I skimmed through #2, and I think ptp4l will support most of what that
profile requires.  They do have an alternate BMC with minor
differences.  If those differences are really important to you, then
you will have to patch ptp4l.

Thanks,
Richard

Re: [Linuxptp-users] ptp4l and network connectivity interruption

[Brian W. <br...@wa...>]

On Thu, Dec 10, 2015 at 4:25 AM, Richard Cochran
<ric...@gm...> wrote:
>> I am having an issue with the ptp4l client and network connectivity. The
>> client works just fine and syncs the hardware clock on an Intel e1000
>> device.
>
> Which device?

It is an Intel 82574L. 8086:10d3

>> However, if anything interrupts that connectivity for a couple of
>> seconds the clock seems to drop the fact that it is synced to a TAI time
>> source with a leap second offset. It will panic that it is behind and jump
>> forward 36 seconds (the current leap second offset). Then a few seconds
>> later when connectivity is restored and resynced, it realizes it is now 36
>> seconds fast and takes 20 minutes or more to work back to the correct time.
>
> IIRC, this problem is due to the fact the e1000 HW and driver requires
> a complete reset when the link goes down.  The old time values gets
> lost, and the driver simply initializes the clock with the current
> system time.
>
>> I am able to reproduce this by temporarily blocking access to 1588 udp
>> ports 319 and 320 through iptables. Wait a few seconds and the clock will
>> jump ahead by the leap second offest. Unblock the udp ports and then the
>> clock begins the long process of adjusting back to the actual time.
>
> Hm, I wouldn't expect that behavior, but it does sound like the link
> loss symptom.
>
>> Is there a setting that I have missed or something I have over looked? The
>> ptp4l client does not have many options. I would think that the clock
>> should maintain the last known offset during the brief interruption.
>
> I think the source of the jump is not in ptp4l but rather in the
> driver or HW.

I am running tests using kernel version 4.1.7. I will try and trace it
down some more.

Looking again it appears it may be the opposite of what I thought.
ptp4l is maintaining the
offset value while the hardware clock has switched back to UTC time. I
am not seeing
anywhere that ptp4l is reseting the offset to 0 during this state.

Connectivity working:
root@host:~> phc_ctl eth0 cmp get
phc_ctl[92833.880]: offset from CLOCK_REALTIME is -36000012151ns
phc_ctl[92833.880]: clock time is 1449766596.912500774 or Thu Dec 10
16:56:36 2015

Ports blocked:
root@host:~> phc_ctl eth0 cmp get
phc_ctl[92834.718]: offset from CLOCK_REALTIME is 7518ns
phc_ctl[92834.719]: clock time is 1449766561.750694117 or Thu Dec 10
16:56:01 2015

Re: [Linuxptp-users] ptp4l and network connectivity interruption

[Richard C. <ric...@gm...>]

On Tue, Dec 08, 2015 at 11:27:29AM -0500, Brian Walsh wrote:
> Sorry if this has been asked before. The archives are unreachable on
> sourceforge. I keep getting an "Error 403 Read access required" when trying
> to view the list archives.

Yes, SF does have issues, and I want to move away from there,
eventually.  In the mean time, you can use the archives on Gmane:

  http://news.gmane.org/gmane.comp.linux.ptp.user
  http://news.gmane.org/gmane.comp.linux.ptp.devel
 
> I am having an issue with the ptp4l client and network connectivity. The
> client works just fine and syncs the hardware clock on an Intel e1000
> device.

Which device?

> However, if anything interrupts that connectivity for a couple of
> seconds the clock seems to drop the fact that it is synced to a TAI time
> source with a leap second offset. It will panic that it is behind and jump
> forward 36 seconds (the current leap second offset). Then a few seconds
> later when connectivity is restored and resynced, it realizes it is now 36
> seconds fast and takes 20 minutes or more to work back to the correct time.

IIRC, this problem is due to the fact the e1000 HW and driver requires
a complete reset when the link goes down.  The old time values gets
lost, and the driver simply initializes the clock with the current
system time.
 
> I am able to reproduce this by temporarily blocking access to 1588 udp
> ports 319 and 320 through iptables. Wait a few seconds and the clock will
> jump ahead by the leap second offest. Unblock the udp ports and then the
> clock begins the long process of adjusting back to the actual time.

Hm, I wouldn't expect that behavior, but it does sound like the link
loss symptom.
 
> Is there a setting that I have missed or something I have over looked? The
> ptp4l client does not have many options. I would think that the clock
> should maintain the last known offset during the brief interruption.

I think the source of the jump is not in ptp4l but rather in the
driver or HW.

Thanks,
Richard

[Linuxptp-users] ptp4l and network connectivity interruption

[Brian W. <br...@wa...>]

Sorry if this has been asked before. The archives are unreachable on
sourceforge. I keep getting an "Error 403 Read access required" when trying
to view the list archives.

I am having an issue with the ptp4l client and network connectivity. The
client works just fine and syncs the hardware clock on an Intel e1000
device. However, if anything interrupts that connectivity for a couple of
seconds the clock seems to drop the fact that it is synced to a TAI time
source with a leap second offset. It will panic that it is behind and jump
forward 36 seconds (the current leap second offset). Then a few seconds
later when connectivity is restored and resynced, it realizes it is now 36
seconds fast and takes 20 minutes or more to work back to the correct time.

I am able to reproduce this by temporarily blocking access to 1588 udp
ports 319 and 320 through iptables. Wait a few seconds and the clock will
jump ahead by the leap second offest. Unblock the udp ports and then the
clock begins the long process of adjusting back to the actual time.

Is there a setting that I have missed or something I have over looked? The
ptp4l client does not have many options. I would think that the clock
should maintain the last known offset during the brief interruption.

Thanks,
Brian

Re: [Linuxptp-users] If linuxptp support ABMC algorithm?

[Richard C. <ric...@gm...>]

On Fri, Dec 04, 2015 at 08:27:11PM +0800, Pengfei zhao wrote:
> Hi,
> As the title. if current release of linuxptp stack support alternate BMC specified in telecom profile?

No, it doesn't support the telecom profle.  We do not have unicast
implemented.

Sorry,
Richard

[Linuxptp-users] If linuxptp support ABMC algorithm?

[Pengfei z. <zha...@ms...>]

Hi,
As the title. if current release of linuxptp stack support alternate BMC specified in telecom profile?
thanks. 		 	   		  

Re: [Linuxptp-users] linuxptp with vlan configuration

[Richard C. <ric...@gm...>]

On Wed, Dec 02, 2015 at 03:34:57PM -0500, Don Ho wrote:
> If you are interested in using ptp4l/phc2sys hardware timestamp on
> vlan, the following instruction is working on my system.
> Someone may ask why VLAN, why I can just have the interfaces on
> different NIC cards. Sure you can. But if you want to reduce the
> number of cables, NIC cards, and may be switches. VLAN is the
> solution.
> 
> Many thanks to Shawn Bohrer for helping me to make this configuration work.

I am suprised that you need to change ptp4l in order to work with VLAN
interfaces.  I thought that I had fixed this in the kernel:

    commit 37dd9255b2f6201195946014600a8d857f846cf4
    Author: Richard Cochran <ric...@gm...>
    Date:   Fri Nov 21 14:16:20 2014 +0100

    vlan: Pass ethtool get_ts_info queries to real device.
    
    Commit a6111d3c "vlan: Pass SIOC[SG]HWTSTAMP ioctls to real device"
    intended to enable hardware time stamping on VLAN interfaces, but
    passing SIOCSHWTSTAMP is only half of the story. This patch adds
    the second half, by letting user space find out the time stamping
    capabilities of the device backing a VLAN interface.

Commit 37dd9255 is in kernel v3.19, and commit a6111d3c is in v3.17.
What kernel version are you using?

Thanks,
Richard

[Linuxptp-users] linuxptp with vlan configuration

[Don Ho <don...@gm...>]

If you are interested in using ptp4l/phc2sys hardware timestamp on
vlan, the following instruction is working on my system.
Someone may ask why VLAN, why I can just have the interfaces on
different NIC cards. Sure you can. But if you want to reduce the
number of cables, NIC cards, and may be switches. VLAN is the
solution.

Many thanks to Shawn Bohrer for helping me to make this configuration work.

- These two NIC cards are working under this configuration
> ethtool -i eth0
driver: ixgbe
version: 4.0.1-k-rh7.1
firmware-version: 0x61c10001
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

> ethtool -i eth6
driver: mlx4_en
version: 3.1-1.0.4 (30 Sep 2015)
firmware-version: 2.35.5100
bus-info: 0000:81:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: yes

- Download linuxptp1.6.tgz
- On the slave servers, my system has eth6, eth6.2, eth6.8, eth6.172,
and I want the ptp traffic to be only on eth6.172

>ethtool eth6
Settings for eth6:
    Supported ports: [ FIBRE ]
    Supported link modes:   1000baseKX/Full
                            10000baseKX4/Full
                            10000baseKR/Full
                            40000baseCR4/Full
                            40000baseSR4/Full
    Supported pause frame use: Symmetric Receive-only
    Supports auto-negotiation: Yes
    Advertised link modes:  1000baseKX/Full
                            10000baseKX4/Full
                            10000baseKR/Full
                            40000baseCR4/Full
                            40000baseSR4/Full
    Advertised pause frame use: Symmetric
    Advertised auto-negotiation: Yes
    Speed: 40000Mb/s
    Duplex: Full
    Port: Direct Attach Copper
    PHYAD: 0
    Transceiver: internal
    Auto-negotiation: off
    Supports Wake-on: d
    Wake-on: d
    Current message level: 0x00000014 (20)
                   link ifdown
    Link detected: yes

> ethtool -T eth6
Time stamping parameters for eth6:
Capabilities:
    hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
    software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
    hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
    software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
    software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
    hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 2 <-- (note: the /dev/ptp2 will be used to run
ptp4l and phc2sys)
Hardware Transmit Timestamp Modes:
    off                   (HWTSTAMP_TX_OFF)
    on                    (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
    none                  (HWTSTAMP_FILTER_NONE)
    all                   (HWTSTAMP_FILTER_ALL)

- Configure hwstamp_ctl
>hwstamp_ctl -i eth6 -r 1 -t 1
current settings:
tx_type 0
rx_filter 0
new settings:
tx_type 1
rx_filter 1

- Modify the following files
port.c  | 3 ++-
 ptp4l.c | 3 ++-
 sk.c    | 2 ++
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/port.c b/port.c
index 3f32433..412fdd9 100644
--- a/port.c
+++ b/port.c
@@ -2562,7 +2562,8 @@ struct port *port_open(int phc_index,
                        pr_err("port %d: PHC device mismatch", number);
                        pr_err("port %d: /dev/ptp%d requested, ptp%d attached",
                               number, phc_index, interface->ts_info.phc_index);
-                       goto err_port;
+                       // Mismatch caused by VLAN, just continue
+                       //goto err_port;
                }
        }

diff --git a/ptp4l.c b/ptp4l.c
index 662e6e6..cefa2de 100644
--- a/ptp4l.c
+++ b/ptp4l.c
@@ -302,7 +302,8 @@ int main(int argc, char *argv[])
                        fprintf(stderr, "interface '%s' does not support "
                                        "requested timestamping mode.\n",
                                iface->name);
-                       goto out;
+                       // Vlan claims it doesn't support HW TS but
real interface does
+                       //goto out;
                }
        }

diff --git a/sk.c b/sk.c
index e80f608..d67a7a6 100644
--- a/sk.c
+++ b/sk.c
@@ -58,6 +58,8 @@ static int hwts_init(int fd, const char *device, int
rx_filter, int one_step)
        cfg.tx_type    = one_step ? HWTSTAMP_TX_ONESTEP_SYNC : HWTSTAMP_TX_ON;
        cfg.rx_filter  = rx_filter;
        req = cfg;
+       // Don't enable HW TS we'll have to do it manually
+       return 0;
        err = ioctl(fd, SIOCSHWTSTAMP, &ifreq);
        if (err < 0)
                return err;

- Build the linuxptp source code and make install. The default
location should be under /usr/local/sbin/

- If you have a ptp4l.conf file then pass it in the command line,
otherwise you need to set each option here. I.e, for running as slave,
add -s. Ignore the line "does not support requested timestamping mode"

>/usr/local/sbin/ptp4l -f /etc/ptp4l.conf -i eth6.172 -p /dev/ptp2
>/usr/local/sbin/phc2sys -s /dev/ptp2 -w
Dec  2 08:57:36 dr-xeon ptp4l: interface 'eth6.172' does not support
requested timestamping mode.
Dec  2 08:57:36 dr-xeon ptp4l: [76304.287] selected /dev/ptp2 as PTP clock
Dec  2 08:57:36 dr-xeon ptp4l: [76304.287] port 1: PHC device mismatch
Dec  2 08:57:36 dr-xeon ptp4l: [76304.287] port 1: /dev/ptp2
requested, ptp-1 attached
Dec  2 08:57:36 dr-xeon ptp4l: [76304.287] port 1: INITIALIZING to
LISTENING on INITIALIZE
Dec  2 08:57:36 dr-xeon ptp4l: [76304.287] port 0: INITIALIZING to
LISTENING on INITIALIZE
Dec  2 08:57:36 dr-xeon phc2sys: [76304.355] phc offset       -19 s2
freq  -13165 delay   1128
Dec  2 08:57:37 dr-xeon ptp4l: [76304.497] port 1: new foreign master
000cec.fffe.0a103c-1
Dec  2 08:57:37 dr-xeon phc2sys: [76305.356] phc offset        -3 s2
freq  -13155 delay   1137
Dec  2 08:57:38 dr-xeon phc2sys: [76306.356] phc offset        29 s2
freq  -13124 delay   1127
Dec  2 08:57:39 dr-xeon ptp4l: [76306.497] selected best master clock
000cec.fffe.0a103c
Dec  2 08:57:39 dr-xeon ptp4l: [76306.497] port 1: LISTENING to
UNCALIBRATED on RS_SLAVE
Dec  2 08:57:39 dr-xeon phc2sys: [76307.356] phc offset        24 s2
freq  -13120 delay   1133
Dec  2 08:57:40 dr-xeon phc2sys: [76308.356] phc offset        27 s2
freq  -13110 delay   1140
Dec  2 08:57:41 dr-xeon ptp4l: [76308.497] master offset       5066 s0
freq +205632 path delay     21301
Dec  2 08:57:41 dr-xeon phc2sys: [76309.356] phc offset        -7 s2
freq  -13136 delay   1174
Dec  2 08:57:42 dr-xeon ptp4l: [76309.497] master offset       6026 s2
freq +206592 path delay     21100
Dec  2 08:57:42 dr-xeon ptp4l: [76309.497] port 1: UNCALIBRATED to
SLAVE on MASTER_CLOCK_SELECTED
Dec  2 08:57:42 dr-xeon phc2sys: [76310.356] phc offset       838 s2
freq  -12293 delay   1130
Dec  2 08:57:43 dr-xeon ptp4l: [76310.497] master offset       5195 s2
freq +211787 path delay     21196
Dec  2 08:57:43 dr-xeon phc2sys: [76311.356] phc offset      5386 s2
freq   -7493 delay   1137
Dec  2 08:57:44 dr-xeon ptp4l: [76311.497] master offset        394 s2
freq +208544 path delay     21196
Dec  2 08:57:44 dr-xeon phc2sys: [76312.357] phc offset      3066 s2
freq   -8197 delay   1127
Dec  2 08:57:45 dr-xeon ptp4l: [76312.497] master offset      -2295 s2
freq +205974 path delay     21248
Dec  2 08:57:45 dr-xeon phc2sys: [76313.357] phc offset     -1221 s2
freq  -11565 delay   1140
Dec  2 08:57:46 dr-xeon ptp4l: [76313.497] master offset      -2915 s2
freq +204665 path delay     21196
Dec  2 08:57:46 dr-xeon phc2sys: [76314.357] phc offset     -3639 s2
freq  -14349 delay   1130