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
<[email protected]>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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
