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

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

On Tue, 2014-05-13 at 17:15 -0600, Mason Winsauer wrote:
> 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.
> 

You would be seeing much different issues if the timestamps were not
working.

Note that generally, PTP hardware does not insert the timestamp into the
packet, but rather returns it to the application via kernel subsystem.
Your hardware may support in-packet timestamp insertion, but that
requires being enabled in the driver. For that to occur, you would have
to issue the correct IOCTL command to the device, and pass it the
correct settings to enable in-packet timestamping, assuming the driver
and hardware support it.

You can however, check the results of a tcpdump/wireshark of a PTP
sequence, and you should see the timestamps of the SYNC message in the
payload of the FOLLOW-UP message.

Thanks,
Jake

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