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
