Re: [Linuxptp-users] Fwd: PTP Timeouts on Kernel 3.14.3-7-desktop

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

On Tue, 2014-05-13 at 15:26 -0600, Mason Winsauer wrote:
> Hey guys,
> 

Hi there,

It seems you mistook a sort of debug message output as an error, when
infact it's part of normal operation. I believe a recent commit into the
head of the project fixes this to be a debug instead of an error, but I
will explain more below.

> 
> I know this is a common question, and have researched the vast
> majority of similar questions, but there still isn't much information
> for my configuration. Also, I'm brand new to PTP as a concept, so
> please forgive my ignorance. I'll start with a quick rundown of the
> current configuration, outputs of relevant programs, etc.
> 
> 
> OpenSuse 13.1, Custom built kernel 3.14.3-7-desktop
>         All required PTP/PPS/PHY options enabled
> Broadcom NetXtreme 5720, 
>         Tigon3 driver version 3.136
> LinuxPTP v. 1.4
> 
> 
> -Output of 'ethtool -T eth0'
>         Time stamping parameters for eth0:
>         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: 0
>         Hardware Transmit Timestamp Modes:
>         off                   (HWTSTAMP_TX_OFF)
>         on                    (HWTSTAMP_TX_ON)
>         Hardware Receive Filter Modes:
>         none                  (HWTSTAMP_FILTER_NONE)
>         ptpv1-l4-event        (HWTSTAMP_FILTER_PTP_V1_L4_EVENT)
>         ptpv2-l4-event        (HWTSTAMP_FILTER_PTP_V2_L4_EVENT)
>         ptpv2-l2-event        (HWTSTAMP_FILTER_PTP_V2_L2_EVENT)
> 
> 
> -Output of 'pmc -u -b 0 'GET CURRENT_DATA_SET''
>         sending: GET CURRENT_DATA_SET
>         90b11c.fffe.2e1b2d-0 seq 0 RESPONSE MANAGMENT
>         CURRENT_DATA_SET 
>         stepsRemoved     0
>         offsetFromMaster 0.0
>         meanPathDelay    0.0
>         
>         
> -Output of 'pmc -u -b 0 'GET TIME_STATUS_NP''
>         sending: GET TIME_STATUS_NP
>         90b11c.fffe.2e1b2d-0 seq 0 RESPONSE MANAGMENT TIME_STATUS_NP 
>         master_offset              0
>         ingress_time               0
>         cumulativeScaledRateOffset +1.000000000
>         scaledLastGmPhaseChange    0
>         gmTimeBaseIndicator        0
>         lastGmPhaseChange          0x0000'0000000000000000.0000
>         gmPresent                  false
>         gmIdentity                 90b11c.fffe.2e1b2d
>         
>         
> 
> -Output of 'ptp4l -S -i eth0 -m -l7'

Your command is correct, except that -l7 outputs *very* verbose log
messages, and is completely unnecessary. Try with -l6 and you should see
less cruft, but most of the useful output.

>         ptp4l[3401.186]: PI servo: sync interval 1.000 kp 0.100 ki
>         0.001000
>         ptp4l[3401.186]: port 1: INITIALIZING to LISTENING on
>         INITIALIZE
>         ptp4l[3401.186]: port 0: INITIALIZING to LISTENING on
>         INITIALIZE
>         ptp4l[3407.916]: port 1: announce timeout
>         ptp4l[3407.916]: port 1: LISTENING to MASTER on
>         ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
>         ptp4l[3407.916]: selected best master clock 90b11c.fffe.2e1b2d
>         ptp4l[3407.916]: assuming the grand master role
>         ptp4l[3407.917]: port 1: master tx announce timeout
>         ptp4l[3407.918]: port 1: setting asCapable
>         ptp4l[3408.917]: port 1: master sync timeout
>         ptp4l[3409.917]: port 1: master sync timeout
>         ptp4l[3409.918]: port 1: master tx announce timeout
>         ptp4l[3410.917]: port 1: master sync timeout
>         ptp4l[3411.917]: port 1: master sync timeout
>         ...
> 

The above messages are output whenever the internal timeouts for sending
announce and sync messages timeout. They only appear at -l7 and are
*not* error messages despite what it appears. The timeout is a standard
timer that we set so that we periodically send a sync and announce
messages as the master. This is standard behavior of the PTP daemon.
Hopefully these messages can be redesigned soon so that they appear less
like a debug. Maybe change the timeout word.

> 
> -Output of 'phc2sys -c eth0 -s /dev/ptp0 -w -m'
>         phc2sys[5786.385]: phc offset    16 s0 freq      +0 delay
>         3968
>         phc2sys[5787.385]: phc offset    -8 s2 freq     -24 delay
>         3984
>         phc2sys[5788.386]: phc offset     0 s2 freq     -24 delay
>         4000
>         phc2sys[5789.386]: phc offset     8 s2 freq     -16 delay
>         3952
>         ...
> 
> 

Here, you see the phc2sys offset, and it actually is very good those
numbers are quite low.

> This will continue on indefinitely. 
> I have heard of systems being incapable of syncing due to time
> disparity, but I have manually synced these clocks in an attempt to
> rule this possibility out. I have also tried increasing all timeouts,
> delays, etc. I have even gone so far as to use NTP as the source for
> PTP, just to see if it would help. It didn't.
> 

The clocks should be synced as it shows here. the values you see above
are in order from left to right:

1) the value in nanoseconds of the last measured offset
2) sN is the current P/I servo state
3) the frequency adjustment we've applied to correct the clock
4) the measured delay of measuring the clock.

These all look great!

> 
> Regardless, from everything I've seen, this appears to be more of a
> driver/kernel issue, though everything I've been able to identify has
> checked out as the proper version, setting, etc. When I was having
> this issue on kernel 3.11, I upgraded to 3.14 to no avail. I'm more
> than willing and happy to send more information upon request and any
> information you guys may have would be hugely helpful.
> 
> 

Are you actually seeing incorrect clock adjustment? The clocks appear to
be in sync. Note that the output of ptp4l you show is actually that
device becoming master, I am curious what the output of the connected
PTP ports are, so we can see how the other end is faring. I think mostly
you simply misinterpreted output of ptp4l.

> Many Thanks,
> Mason
> 

Hope this helps!

Regards,
Jake