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
