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...
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.
On Fri, Jun 18, 2021 at 3:05 AM Keller, Jacob E <[email protected]>
wrote:
>
>
> > -----Original Message-----
> > From: Keller, Jacob E
> > Sent: Thursday, June 17, 2021 5:04 PM
> > To: 'Dale Smith' <[email protected]>; Joseph Matan
> > <[email protected]>
> > Cc: [email protected]
> > Subject: RE: [Linuxptp-users] Intel NICs PTP Performance Comparison
> >
> >
> >
> > > -----Original Message-----
> > > From: Dale Smith <[email protected]>
> > > Sent: Thursday, June 17, 2021 3:04 PM
> > > To: Joseph Matan <[email protected]>
> > > Cc: [email protected]
> > > Subject: Re: [Linuxptp-users] Intel NICs PTP Performance Comparison
> > >
> > > So how in the would could *more* traffic cause a *smaller* delay?
> > >
> >
> > EEE low power ethernet kicking in, which puts the device into a low
> power state
> > that has a higher latency to wake up. You could check "ethtool
> --show-eee" to see
> > if the device supports it and what the status is.
> >
>
> I missed that you ruled out EEE already. I wonder if i218 supports it
> without supporting the options to disable it though.... I'm not certain.
>
> Thanks,
> Jake
>
> > > Very curious.
> > >
> > > Wild Guess, maybe interrupt coalescing is going on, and with more
> > > packets, it's actually responding sooner?
> >
> > This is unlikely, since timestamps are captured in hardware, so I don't
> think it
> > should impact the latency with regards to the actual timestamps.
> >
> > >
> > > Another guess, that somehow the determination of the timestamps are
> > > just plain wrong. Like maybe they were fudged to some value while
> > > under heavy load, and are way more off when under light load?
> > >
> >
> > I don't think this is the case for Intel devices.
> >
> > > Just guesses as I said. I don't do 1588 much anymore, but this is
> > > very intriguing. Please report back if you ever get to the bottom of
> > > this.
> > >
> > > -Dale
> > >
> > >
> > > _______________________________________________
> > > Linuxptp-users mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/linuxptp-users
>
_______________________________________________
Linuxptp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
