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

[Mason W. <mas...@gm...>]

Well this is all very good news.


> 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.


I suppose not, if that is in fact the case. It would seem as though my
misinterpretation stemmed from the fact that when I actually tried to
transmit a UDP message, it was not able to see PTP evidence when checking
at packet scope. Wireshark reported the protocols used as
'eth:ip:udp:data', though, correct me if I'm wrong, I would see evidence
both here and in other areas of a PTP stamp. It was a very simple test,
just writing a message through either Netcat or /dev/udp/, so there's as
good of a chance that my fallacy lies there as anywhere else.

Again, thank you so very much for your help,
Mason


On Tue, May 13, 2014 at 4:50 PM, Keller, Jacob E
<jac...@in...>wrote:

> 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
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
>