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

[Miroslav Lichvar <mlichvar@redhat.com>]

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