Re: [PATCH 0/5] timekeeping: Reduce magnitude of ntp_error

[David Woodhouse <dwmw2@infradead.org>]

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

On Thu, 2026-10-22 at 15:52 +0200, Miroslav Lichvar wrote:
> On Thu, Oct 22, 2026 at 11:05:18AM +0200, Rodolfo Giometti wrote:
> > On 21/10/26 16:37, David Woodhouse wrote:
> > > Ping? Patches 1-4 of this should be ready to merge now.
> > > 
> > > So is number 5 as far as I'm concerned, but I'm happy to entertain
> > > further discussion if anyone has an opinion they want to share.
> > 
> > Number 5 changes the timestamps PPS_FETCH returns to userspace, so I'd
> > still like an explicit OK from its users, such as chrony and others,
> > before it goes in.
> 
> I'm ok with it. As described, I don't think it's going to cause any
> issues, especially for low-rate PPS, but I don't like much that the
> clock is inconsistent with other sources of timestamps that the
> application is getting. That can be addressed later.

Yeah, I do wonder if at least adjtimex() should report a 'corrected'
time. But as you say, we can address that later. I'm still trying to
work out the get/set reference stuff which is what I need to do next.

> For the PTP_SYS_OFFSET_EXTENDED ioctl, is there a possibility the
> application could see an out-of-order system clock timestamp in the
> list?

Theoretically, the snapshot correction is trading monotonicity for
accuracy — it asks ktime_get_snapshot_id() to tell the *truth* by
compensating for the known ntp_error, even if the time reported is
"earlier" than a timestamp which was previously reported.

So the time reported by a tickless kernel can wander around the "ideal"
all it likes, and userspace still gets to discipline the ideal. 

In practice, it's only going to be non-monotonic w.r.t. the "fast" time
reported by clock_gettime(), not with other samples obtained through
ktime_get_snapshot_id(). 

The first patch in this series fixes the known case where ntp_error
retrospectively jumps, which would cause such a non-monotonicity in the
snapshots themselves.


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