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.
The first thing I would do is try and put the laptop and the 82579 device back-to-back and see if your problem persists (eliminate the boundary-clock form the equation). 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? 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? 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? 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. 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. Hope this is of some help, Dave Ertman > -----Original Message----- > From: David Lamparter [mailto:[email protected]] > Sent: Sunday, September 22, 2013 2:28 PM > To: [email protected] > Cc: Allan, Bruce W > Subject: [E1000-devel] 82579LM excessive 1588/PTP pdelay? > > Hi e1000e list, > Hi Bruce as e1000e 1588 author, > > > 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? > > Peer system is an Extreme Networks X440 switch, and I'm using > linuxptp-1.2 on the laptop. The software works fine on a TI BeagleBone > (ARM/AM3359) with the same switch (850~1100ns delay @ 100mbit). > > Chip: > 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit > Network Connection [8086:1502] (rev 04) > Subsystem: Hewlett-Packard Company Device [103c:179b] > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 0 > Interrupt: pin A routed to IRQ 48 > Region 0: Memory at d4400000 (32-bit, non-prefetchable) > [size=128K] > Region 1: Memory at d443a000 (32-bit, non-prefetchable) [size=4K] > Region 2: I/O ports at 5020 [size=32] > Capabilities: [c8] Power Management version 2 > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1- > ,D2-,D3hot+,D3cold+) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME- > Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ > Address: 00000000fee00418 Data: 0000 > Capabilities: [e0] PCI Advanced Features > AFCap: TP+ FLR+ > AFCtrl: FLR- > AFStatus: TP- > Kernel driver in use: e1000e > > $ ethtool -i eth0 > driver: e1000e > version: 2.2.14-k > firmware-version: 0.15-4 > > Kernel is 3.9.4, I didn't see relevant changes after that, hope I didn't miss > anything. > > Laptop is a HP EliteBook 8470p. It has a MEI/AMT, in case *that* screws up > the timing. > > So, uh... how do I go about debugging this? I don't really have any idea to > start out with. Source could be anything from HW to MEI to BIOS > interference to driver bug to API misuse... > > Cheers, > > > -David > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack > includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends > 9/22/13. > http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clk > trk > _______________________________________________ > 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 ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&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
