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
