Re: [PATCH 0/5] timekeeping: Reduce magnitude of ntp_error
From: David Woodhouse
Date: Thu Oct 22 2026 - 12:20:59 EST
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:
smime.p7s
Description: S/MIME cryptographic signature