Linux PPS and PHC timestamps vs. clock_gettime() — input wanted

Linux PPS and PHC timestamps vs. clock_gettime() — input wanted

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]

In Linux I've been fixing the handling of ntp_error — the kernel's own
record of the difference between the time adjtimex() asked it to
report, and the time it *actually* reports due to the integer
precision of its tick arithmetic. On a tickless kernel that transient
error can reach tens of microseconds before the kernel's dithering
corrects it. In the series¹ I'm working on, that is reduced to
nanoseconds.

The final patch of the series changes the system timestamps reported by
PPS_FETCH and the PTP PTP_SYS_OFFSET family of ioctls. They'll now
report the time the kernel *wanted* to report at the moment of the
paired timestamp, rather than the output of the tick-based timekeeping
which sawtooths around that ideal.

These are *paired* timestamps — the system clock sampled against a
pulse edge or a PHC reading — so what matters is that the pair is
accurate, not that the system half of it matches other reads of the
system clock.

The difference from clock_gettime(CLOCK_REALTIME) at the same instant
is just a known error which the kernel was already committed to
eliminating.

With the rest of the series applied (removing the known cases where
that ntp_error delta accumulates significant values), that difference
measured at up to ±10ns on a tickless kernel, so this part is belt and
braces. But ntp_error can still accumulate over a long tickless idle
period, and when it has, there's no reason to knowingly hand a consumer
a timestamp which we *know* to be wrong.

Miroslav has already acked this correction (which is patch 6 of the
series) from the chrony point of view²; it would be good to have an ack
from the ntpd side too, if possible.

For ntpd I can see two places that the now-corrected timestamps are
consumed: PHC-to-system offsets — whether measured by ntpd itself or by
phc2sys feeding ntpd over SHM — are now against the intended timeline,
and the PPSAPI timestamps into refclock_atom and the PPS-capable
drivers.

Is there anything in ntpd which assumes those timestamps and
clock_gettime() are on exactly the same timeline, or any other reason
the correction could cause a problem?

¹ https://lore.kernel.org/all/20261106030856.2538039-1-dwmw2@infradead.org/
² https://lore.kernel.org/all/atoVLqWfyJtCfci2@localhost/

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6179 bytes --]