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] [day] [month] [year] [list]

Message-ID: <aNJZgRkY66BCu9Aj@localhost>
Date: Tue, 23 Sep 2025 10:25:37 +0200
From: Miroslav Lichvar <mlichvar@...hat.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Kurt Kanzenbach <kurt@...utronix.de>,
	Jacob Keller <jacob.e.keller@...el.com>,
	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>,
	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 Sat, Sep 13, 2025 at 11:22:12PM +0200, Sebastian Andrzej Siewior wrote:
> If I do
> | ntpperf -i X … -I -r 1000 -t 2
> 
> then there is no loss and on other side I see
> 
> | NTP packets received       : 2201
> | NTP timestamps held        : 2101
> | NTP daemon TX timestamps   : 200
> | NTP kernel TX timestamps   : 901
> | NTP hardware TX timestamps : 1100
> | tx_hwstamp:2101
> 
> Here the tx_hwstamp counter colorates with "NTP timestamps held". Does
> it this make any sense? I don't see this matching with the "larger" runs
> where ntpperf reports loss.

The serverstats counters are for timestamps that were served to the
client, which is different from timestamps it got from the kernel.

Some HW timestamps are not used because chronyd is not tracking the
PHC yet. That takes at least one second in default configuration (it
can be reduced by the minpoll option of hwtimestamp). If there was no
other NTP activity on that interface before the test was started, in
the first second of the test (i.e. 50% of -t 2, or 10% of -t 10)
chronyd will be serving kernel TX timestamps, even though it is
receiving HW timestamps from the kernel. To minimize that effect, you
can run a client chronyd instance in background polling the server
once per second (minpoll 0 maxpoll 0) and wait for a few seconds
before starting ntpperf after the server chronyd instance was
restarted.

There is a 2-packet delay in the interleaved mode for each client
(ntpperf has a warmup phase to avoid counting basic responses). With
-r 1000 ntpperf simulates 100 clients. So, for the 2201 requests
chronyd received, the first 200 (2 * 100 clients) responses had a
daemon TX timestamp, 901 responses had a kernel TX timestamp before
the PHC tracking initialized in the first second, and the remaining
1100 responses had a HW TX timestamp.

The "NTP timestamps held" matching tx_hwstamp is a coincidence. It
is not related to the number of HW timestamps received from the kernel
or served to the client. Until chronyd starts dropping timestamps to
not exceed clientloglimit, it's just counting requests in interleaved
mode, i.e. the number of requests minus the first request from each
client: 2201 - 1 * 100 = 2101.

-- 
Miroslav Lichvar