In case you haven't solved this yet - just a few more things to try/look into (at bottom).
> -----Original Message----- > From: David Lamparter [mailto:[email protected]] > Sent: Monday, September 23, 2013 1:23 PM > To: Ertman, DavidX M > Cc: David Lamparter; [email protected]; Allan, Bruce W > Subject: Re: [E1000-devel] 82579LM excessive 1588/PTP pdelay? > > Hi Dave, > > > > -----Original Message----- > > > I'm trying to use an 82579LM (connected to a QM77 chipset laptop) > > > for > > > 802.1AS/1588v2 time sync. I'm seeing excessive pdelays: > > > > > > 1000mbit FD - 7300ns > > > 100mbit FD - 23000ns > > > 10mbit FD - 90000ns > > > > > > The delay being speed dependent already is a bug to start out with, > > > it should only depend on cable length really. The default cutoff > > > for bringing up time sync is 3800ns, so it doesn't even come up. If > > > I manually raise that bar, I do get a stable sync - by tens of > > > nanoseconds in fact, so hardware timestamping is correctly working. > There just seems to be an offset somewhere... > > > > > > Also, interestingly the switch side always says 7300ns, no matter the > speed. > > > So it's direction dependent? > > > [...] > > On Mon, Sep 23, 2013 at 04:39:28PM +0000, Ertman, DavidX M wrote: > > Hello David, > > > > From what I understand from your email, you are syncing clocks between > > an 82579LM device and a laptop through a boundary-clock in a switch. > > Sorry, no. I should've been more clear. The 82579LM is *in* the Laptop. > Also, the switch participates as normal clock, most of the time I only have > the > switch and my laptop up. > > (Switching roles like the grandmaster clock around didn't change anything > about the delay.) > > I still have one option I haven't tried, which is connecting my 82579LM laptop > to the BeagleBone and see what that results in. (I only got the BeagleBone's > 1588 to work very recently, thus didn't have the chance to connect it straight > to the laptop yet.) > > > You are correct, that if you are using HW time stamping (1588) then > > the speed of the link should not have any effect on the packet delay. > > Could this be an issue with how the switch is performing its > > boundary-clock duties? > > The setup with the X440 and the BeagleBone works fine, same LAN port and > same Linux PTP software as on the laptop. Hence I'd rank down the switch > and the software to the bottom of possible problem sources. > > > I am not completely familiar with how linuxptp implemented PTP, but > > there is a new version of linuxptp (1.3) on sourceforge - possibly try > > the new version? > > Oh, I didn't see the 1.3 release yet. I'll update in a bit - though, as > above, the > software works fine on the BeagleBone. > > > In the documentation of linuxptp it does not list the 82579 device as > > supporting PHC time stamps (even though it does), could they be > > falling back to a SW timestamp? Also, I am assuming you are using > > V2_L4 PTP, maybe if you try putting the devices back-to-back, try > > V2_L2 PTP packets? > > No, it's not falling back to software timestamping. The measured pdelay is > constant down to around 10ns. SW timestamps don't even get close to that, > it's lucky if you get 1µs (I tried). > > Also, this is 802.1AS, there is no L4 profile, it's always V2_L2. I can try > non- > 802.1AS 1588v2 between the BeagleBone and the laptop though. > > > As far as the delay being direction dependent, PTP is designed to > > handle a non-symmetrical path delay. > > > > I am assuming that you compiled 1588 clock support into the kernel - > > so you have a fully populated output when you query "ethtool -T ethX". > > If the system is using the RX filter HWTSTAMP_FILTER_ALL, that could > > be a problem, and there is a known issue with rapid fire time > > stamping. Hopefully it is using the proper > > HWTSTAMP_FILTER_PTP_V2_EVENT or SYNC or DELAY_REQ (EVENT is > probably > > the easiest to use without mucking around). Or, even a more specific > > filter, but it is not necessary. > > Hm, how do I check what filter it is using? > > 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) > all (HWTSTAMP_FILTER_ALL) > ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) > ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) > ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC) > ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) > ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC) > ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ) > ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT) > ptpv2-sync (HWTSTAMP_FILTER_PTP_V2_SYNC) > ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ) > > So kernel support seems to be all there. > > > Maybe watching the content of the PTP packets to determine what is > > getting passed back and forth might give some insight into what is > > happening. > > The problem is that I can only extract very little timing information from a > packet capture... I have no way to get a clock sync to attribute delays, nor > do > I get visibility on where/when/why the NIC timestamps packets... > > > -David After just a *very* brief glance at the code of linuxptp, it has some logic to try implementing a few different HWTSTAMP filters (hwtstamp_ctl.c) and SOF_TIMESTAMPING settings (ptp4l.c). It also can run with raw, UDP and UDP_V6 sockets. You would probably have to do some basic debugging to see what was actually happening in the background (e.g. see what is being set with the socket and being set to the device with the IOCTL calls). Also, check the logs on your machine - there are a multiple places in the code that output information via print to LOG_ERR, LOG_INFO, etc. As far as watching the PTP packets, I was thinking more along the lines of seeing how the PTP implementation was being carried out. Checking to see if multiple SYNC packets were being sent, or maybe not being responded to like they should. More tracing the flow of the synchronization rather than trying to capture time data. Although, with something like Wireshark for Linux, you could fairly easily check the timestamps in the Follow Up (since 82579 does not have one-step clock hardware) and Delay Response packets, for whatever value that might provide :-) One other thing to check into: Is your link partner EEE capable? There has been some conjecture (but no evidence) that EEE could negatively impact PTP. Try "ethtool --show-eee ethX" , and you can set EEE value with "ethtool --set-eee ethX". Try completely disabling EEE (on both ends of the link) and see what happens. Hope this helps, Dave Ertman ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
