Dear gents, let me just briefly follow up on the past thread on "TX timestamp timeouts". To sum up: on the my part the problem seems gone.
In the three months that have passed, I've built another computer with some i210 and i82574 NIC's inside (related to my thread on precise timestamping when capturing). I took some unsold ATX mobo with quad Intel NIC's and added some i210's in PCI-e slots. I also ended up with some fiber NIC's that cannot be synced by external PPS, and thus I needed to sync my system timebase too, and I did that by PTP on one of the Intel NIC's. This new computer already has Debian 9 Stretch, and the kernel is 4.14.10. On tuesday I had another chance to try PTP against the TC switch at a substation with IEC61850 running. The "sampled values" (not GOOSE) traffic is a rapid fire of 3.5 Mbps in 124B packets, i.e. about 3.5kpps, on a 100Mbps network. The PTP is mixed in that. And, ptp4l on the Intel NIC's worked fine. This time I prepared the interface for PTP (and for the capturing too) using the following script: ethtool --set-eee $netdev eee off ethtool --pause $netdev rx off tx off autoneg off # unfortunately, forced mdix off is exclusive with autoneg off :-( #ethtool -s $netdev mdix off ethtool -s $netdev speed 100 duplex full autoneg off ip link set dev $netdev up There was not a hint of any problem, neither in ptp4l (TX timestamp timeout) nor in t-shark doing the HW-timestamped capturing. This is probably my last message with this subject, thanks for all your attention and help. Frank On 9 Dec 2017 at 16:26, linuxptp-devel@lists.sourcefo wrote: > On 7 Dec 2017 at 21:55, Keller, Jacob E wrote: > > > 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. > > > Thanks for the useful information! > > > 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? > > > > So uh... ASPM on PCI-e may have been eliminated a couple years ago, > but we still have the Ethernet-level energy saving to sort out? > I recall that even low-end unmanaged SoHo switches now support some > "green" functions on Gb Eth... makes me wonder if EEE is the techical > substance of the "green" word printed on D-Link's packaging carton. > Wikipedia mentions 802.3az... ahh yes, and so does "man ethtool", > referring to "eee". > > # ethtool --show-eee eth0 > EEE Settings for eth0: > EEE status: enabled - inactive > Tx LPI: 0 (us) > Supported EEE link modes: 100baseT/Full > 1000baseT/Full > Advertised EEE link modes: 100baseT/Full > 1000baseT/Full > Link partner advertised EEE link modes: Not reported > > The Ethernet port is now connected straight to a 2nd-generation > Meinberg grandmaster card, called the IMS-TSU. I understand the > ethtool listing in the following way: > the IMS-TSU does not support EEE. > All the better. > > A month ago, also in my lab, the eth0 was attached directly to a > 3rd-generation Meinberg grandmaster card, called the HPS100. > Not sure, maybe it supports EEE? That's when the TX timeouts were > occurring a couple times a day, when combined with my i219LM eth0. > > On site, eth0 was attached to a switch by Ruggedcom, working as a TC. > Makes me wonder if the switch supports EEE. Time for me to check the > manual. Makes me wonder if EEE combined with the GOOSE multicasts > could result in the high frequency of TX timestamp timeouts > observed... > > Thanks for all the tips! :-) > > Frank ------------------------------------------------------------------------------ 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
