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