Re: [Intel-wired-lan] [PATCH iwl-next] igb: Retrieve Tx timestamp directly from interrupt

[Miroslav Lichvar <mlichvar@redhat.com>]

On Fri, Sep 12, 2025 at 11:04:24AM +0200, Kurt Kanzenbach wrote:
> 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

ntpperf sending 200k requests per second for 10 seconds is 2 million,
but the sums of RX or TX timestamps in both your results show it
handled only about half of that. The CPU seems to be too slow for such
rate in either case.

I was testing it with an Intel E3-1220 v6 (4 cores, no hyperthreading)
and I set "-r 200000" to roughly match the maximum rate my machine can
handle before the patch. Can you please try adjusting the rate to
minimize the loss in the test without the patch first?

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

Your config looks good to me. Here is mine, but it is functionally
equivalent wrt this test:

hwtimestamp i350b
clientloglimit 1000000000
local
allow

> 
> |########## 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

-- 
Miroslav Lichvar