Re: [PATCH v4 3/4] pps: Always use ktime_get_snapshot_id() for pps_get_ts()

[Rodolfo Giometti <giometti@enneenne.com>]

On Sat, 2026-09-26 at 21:38 +0100, David Woodhouse wrote:
> So yes, the specific code path you're looking at *does* get slightly
> longer (50ns to the counter read instead of 30ns).
[...]
> However, they are *entirely* in the noise, as there's about 600 ns of
> hardware and 2-4 *microseconds* of software latency before we even get
> there.

Thanks for measuring it, and on real hardware with a real edge. That
answers my concern: ~20 ns of constant cost against microseconds of
latency upstream of the handler is not something PPS can see, and
trading it for the removal of a non-constant error is the right
trade. It is arm64 rather than the 32-bit board I asked about, but I
accept the argument holds there too, since the software latency only
gets larger.

There is still one thing I want to be sure we agree on, about what
ts_real means for userspace.

Today, without CONFIG_NTP_PPS, ts_real comes from ktime_get_real_ts64(),
which is the same value userspace reads with
clock_gettime(CLOCK_REALTIME). A PPS timestamp and a clock_gettime()
reading are identical by construction: both are the sanitized clock.
With CONFIG_NTP_PPS the same held so far, since ktime_get_snapshot_id()
also returned the sanitized value.

After 1/4 and this patch that is no longer true. Your 1/4 says it
explicitly: callers of ktime_get_snapshot_id() now receive the ideal
time, "not the sanitized version provided to gettimeofday()". So ts_real
becomes the ideal line, while clock_gettime(CLOCK_REALTIME) keeps
returning the sanitized one, and the two differ by ntp_error at the
instant of the edge.

For hardpps this is clearly what we want, and your 1/4 and 2/4 make
that case. For userspace I am less sure. chrony and ntpd compare PPS
timestamps against other sources whose timestamps come from
clock_gettime(), i.e. from the sanitized clock, so after this series
the two would be referenced to different lines, ntp_error apart.
Miroslav, is that something chrony would notice? And David, how large
can that difference get in practice? Your 1/4 says the divergence can
span many ticks under NO_HZ.

Since the main users of ts_real are chrony and ntpd, not the kernel,
I would like an Acked-by from their maintainers before I ack this
patch. They are the ones who will have to live with the new semantics,
so they should know what is coming and agree with it.

So for v5 please put this in the commit message, not only in the
thread: why ktime_get_real_ts64() is inaccurate (the quantisation of
the multiplier), that ts_real is now the ideal NTP-disciplined time
rather than what clock_gettime() returns, the order of magnitude of
the difference, and a short summary of the latency numbers above.
Whoever runs git blame on pps_get_ts() in a few years should not have
to find this thread.

Ciao,

Rodolfo