> -----Original Message----- > From: Frantisek Rysanek [mailto:frantisek.rysa...@post.cz] > Sent: Thursday, December 07, 2017 12:41 PM > To: linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] Despite the patch, "timed out while polling for > tx > timestamp" keeps happening > > On 7 Dec 2017 at 18:47, Keller, Jacob E wrote: > > > > => the Intel NIC hardware is possibly sensitive to "irrelevant" > > > contents in the traffic. I can come up with the following candidate > > > culprits/theories: > > > - absence of the VLAN tag > > > - correction values of 10-20 ms > > > - other mcast traffic interfering > > > - higher/different actual jitter in the messages? > > > > > > > Which device (and driver) are you using? (I can't see it in the > > > > history). > > > > > > > On the ptp4l client? > > > The PC is a pre-production engineering sample panel PC by Arbor/TW, > > > with Intel Skylake mobile, the NIC that I'm using is an i219LM > > > integrated on the mothereboard (not sure if this has a MAC on chip > > > within the PCH/south, or if it's a stand-alone NIC). Of the two Intel > > > NIC chips, this one is more precise. The kernel is a fresh vanilla > > > 4.13.12 and the e1000e driver came with it. > > > I'm attaching a dump of dmesg and lspci. Ask for more if you want. > > > > > > Frank Rysanek > > > > Do you know the packet rate for Tx packets? (How often is it > > requesting timestamps)? There was a recent-ish problem I believe we > > fixed but it appears to be in 4.13: 5012863b7347 ("e1000e: fix race > > condition around skb_tstamp_tx()", 2017-06-06), but that definitely > > should be in the 4.13 kernel.. > > > > There should also be statistics you can check in ethtool stats on the > > device. Could you try checking if tx_hwtstamp_timeouts is > > incrementing? Also whether tx_hwtstamp_skipped? > > > > Thanks, > > Jake > > Dear Mr. Keller, thanks for your immediate responses and for the job > that you're doing on the drivers. You have my deepest respect. > > Yes that patch is in my e1000e driver: > https://patchwork.ozlabs.org/patch/758160/ > That's the patch mentioned in the subject of this e-mail thread :-) > > ptp4l sends one PDelay Request per second, and answers one > PDelay Request received from the upstream switch (per second). > That's three PTP messages transmitted per second. > There is no other TX traffic on that same port. >
Ok, so that means it probably isn't caused by too many requests for the device to handle. > About ethtool stats - I now understand that you mean the output of > ethtool -S, namely the lines > tx_hwtstamp_timeouts: 0 > tx_hwtstamp_skipped: 0 > rx_hwtstamp_cleared: 0 > This is what they look like now, that the error does not occur. > In a few days I will probably have a chance to try it in the field > again, on a PTP TC switch wih GOOSE flooding the network... that's > where the misbehavior was most stubborn. Well now I know what to look > at :-) I'll report more numbers when I have some. > Ok good. If you see Tx timeouts again, try to measure the stats here and see if any of these increment. If they do, that's a sure indication that the driver was not able to obtain and send the timestamp to the stack. If they *do not* increment, then that means that the driver was likely too late when responding with the Tx timestamp, which is a separate problem. Oh.. It's possible that the device might be going to sleep too quickly.. can you check to see if it supports EEE? "ethtool --show-eee <dev>"? This causes the device to go into low power link mode which substantially increases the latency for actual Tx packets (when there's little to no traffic). That might be the reason under some circumstances why you see dropped timestamps, if EEE is enabled? > BTW do you know what volume of RX buffers does the i219LM have on > chip? Or its companion MAC integrated in the PCH, if the i219 is just > a PHY. > > Frank Rysanek > The i219 is a MAC, however I don't know the volume of buffers on the chip unfortunately. Most of my work is on the i40e, fm10k, and ixgbe, though I've helped some of the work on PTP for other parts. (And, as far as I know, I'm the only one here who monitors the ptp4l list directly). Thanks, Jake ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
