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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aKVxDjocY3uQr342@localhost>
Date: Wed, 20 Aug 2025 08:54:06 +0200
From: Miroslav Lichvar <mlichvar@...hat.com>
To: Kurt Kanzenbach <kurt@...utronix.de>
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 Tue, Aug 19, 2025 at 04:50:23PM +0200, Kurt Kanzenbach wrote:
> Installed ntpperf on one machine and chrony (v4.6) on the second. In the
> chrony config there is 'hwtimestamp enp1s0'. I did run the first example
> in ntpperf's README with the following results. 'rate' seems to be
> higher with my patch applied. Anyway, your ntpperf output looks
> completely different. What parameters are you using? I just want to
> reproduce your results first.
> 
> root@...1:~/ntpperf# ./ntpperf -i enp1s0 -m 6c:b3:11:52:39:15 -d 192.168.123.1 -s 172.18.0.0/16 -B -H

Interleaved mode needs to be selected by the -I option (instead of -B)
in order for the server to enable SW+HW TX timestamps for the
responses it sends back to the client.

My ntpperf command line also had "-x 1.05" to increase the rate in
smaller steps and "-o 0.000000500" to print the offset between the
server TX and client RX timestamp instead of the offset between
server's TX and RX timestamp (response time), but that requires the
NIC PHCs to be synchronized to each other over a different network
link and the -o value to be calibrated for the delays in timestamping
and cable. It's not important for this issue, no need to bother with
that.

> * ntpperf with igb patch applied

> 129721   12972   0.00%   0.00% 100.00%   0.00%    +7934  +49386 +229427  17600
> 194581   16384   0.00%   0.00% 100.00%   0.00%   +10760  +54961 +248325  18860
> 291871   16384   0.00%   0.00% 100.00%   0.00%   +13207  +57193 +248870  16908
> 437806   16384  25.42%   0.00%  74.58%   0.00%  +211479 +275061 +703480  20529
> 
> * ntpperf without igb patch applied

> 129721   12972   0.00%   0.00% 100.00%   0.00%    +2670  +14699 +242395   6692
> 194581   16384   0.00%   0.00% 100.00%   0.00%    +2520  +19712 +329254   9571
> 291871   16384   1.37%   0.00%  98.63%   0.00%    +2818  +77396 +15480693 182286
> 437806   16384  24.69%   0.00%  75.31%   0.00%  +108662 +246855 +2306431  38520

Those results look the same within few percent, as I'd expect with
the basic NTP mode (-B option), which doesn't enable server's TX
timestamping. Normally, I see larger differences in subsequent runs in
the same configuration.

-- 
Miroslav Lichvar