Message-ID: <87ikhodotj.fsf@jax.kurt.home>
Date: Fri, 12 Sep 2025 11:04:24 +0200
From: Kurt Kanzenbach <kurt@...utronix.de>
To: Miroslav Lichvar <mlichvar@...hat.com>, Jacob Keller
 <jacob.e.keller@...el.com>
Cc: Tony Nguyen <anthony.l.nguyen@...el.com>, Przemek Kitszel
 <przemyslaw.kitszel@...el.com>, Andrew Lunn <andrew+netdev@...n.ch>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
 <pabeni@...hat.com>, Richard Cochran <richardcochran@...il.com>, Vinicius
 Costa Gomes <vinicius.gomes@...el.com>, Sebastian Andrzej Siewior
 <bigeasy@...utronix.de>, intel-wired-lan@...ts.osuosl.org,
 netdev@...r.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH iwl-next] igb: Retrieve Tx timestamp
 directly from interrupt

On Wed Aug 20 2025, Miroslav Lichvar wrote:
> On Tue, Aug 19, 2025 at 04:31:49PM -0700, Jacob Keller wrote:
>> I'm having trouble interpreting what exactly this data shows, as its
>> quite a lot of data and numbers. I guess that it is showing when it
>> switches over to software timestamps.. It would be nice if ntpperf
>> showed number of events which were software vs hardware timestamping, as
>> thats likely the culprit. igb hardare only has a single outstanding Tx
>> timestamp at a time.
>
> The server doesn't have a way to tell the client (ntpperf) which
> timestamps are HW or SW, we can only guess from the measured offset as
> HW timestamps should be more accurate, but on the server side the
> number of SW and HW TX timestamps provided to the client can be
> monitored with the "chronyc serverstats" command. The server requests
> both SW and HW TX timestamps and uses the better one it gets from the
> kernel, if it can actually get one before it receives the next
> request from the same client (ntpperf simulates up to 16384 concurrent
> clients).
>
> When I run ntpperf at a fixed rate of 140000 requests per second
> for 10 seconds (-r 140000 -t 10), I get the following numbers.
>
> Without the patch:
> NTP daemon TX timestamps   : 28056
> NTP kernel TX timestamps   : 1012864
> NTP hardware TX timestamps : 387239
>
> With the patch:
> NTP daemon TX timestamps   : 28047
> NTP kernel TX timestamps   : 707674
> NTP hardware TX timestamps : 692326
>
> The number of HW timestamps is significantly higher with the patch, so
> that looks good.
>
> But when I increase the rate to 200000, I get this:
>
> Without the patch:
> NTP daemon TX timestamps   : 35835
> NTP kernel TX timestamps   : 1410956
> NTP hardware TX timestamps : 581575            
>
> With the patch:
> NTP daemon TX timestamps   : 476908
> NTP kernel TX timestamps   : 646146
> NTP hardware TX timestamps : 412095
>

Sebastian found a machine with i350 and gave me access.

I did run the same test as you mentioned here. But, my numbers are
completely different. Especially the number of hardware TX timestamps
are significantly lower overall.

Without the patch:

./ntpperf -i eno8303 -m X -d Y -s Z -I -r 200000 -t 10

NTP daemon RX timestamps   : 0
NTP daemon TX timestamps   : 565057
NTP kernel RX timestamps   : 100208
NTP kernel TX timestamps   : 281215
NTP hardware RX timestamps : 882823
NTP hardware TX timestamps : 136759

With the patch:

NTP daemon RX timestamps   : 0
NTP daemon TX timestamps   : 576561
NTP kernel RX timestamps   : 99232
NTP kernel TX timestamps   : 255634
NTP hardware RX timestamps : 868392
NTP hardware TX timestamps : 135429

What am I doing wrong? Here's my chrony config:

|########## i350 NTP performance regression test ###########
|local stratum 10
|allow X
|allow Y
|allow Z
|
|hwtimestamp eno0
| 
|clientloglimit 134217728
|log measurements statistics tracking
|logdir /var/log/chrony

Thanks,
Kurt

Download attachment "signature.asc" of type "application/pgp-signature" (862 bytes)

Powered by blists - more mailing lists