On 6/18/2021 2:10 AM, Joseph Matan wrote: > The original state of the NIC (after reset) is: > > ethtool --show-eee eth0 > EEE Settings for eth0: > EEE status: enabled - inactive > Tx LPI: 17 (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 > > ethtool -a eth0 > Pause parameters for eth0: > Autonegotiate: on > RX: on > TX: on > > So the first thing I thought was that it's obviously something with eee > getting into action. > (if it was the flow-control in action, I would expect the delay to get > bigger...) > > But just to be sure, I ran: > > ethtool -A eth0 autoneg off rx off tx off > ethtool -a eth0 > Pause parameters for eth0: > Autonegotiate: off > RX: off > TX: off > > ethtool --set-eee eth0 eee off > EEE Settings for eth0: > EEE status: disabled > Tx LPI: 17 (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 > > But there was no effect... > Since I still think it's eee in action, my only guess is that turning > eee off via ethtool doesn't really work...
The only thing I can think of here that would cause this behavior is EEE, but it is possible I am missing something else. > I'll try to see if I can dump the value from the relevant register (and > not use ethtool). > I just wonder how this issue was ever mentioned before in this forum... > From what I see this NIC is quite common. > I guess no one else looked at the delay all that closely? _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
