Re: [PATCH 5/5] [DO NOT MERGE] timekeeping: Apply extrapolated ntp_error to clock snapshots

From: David Woodhouse

Date: Fri Oct 02 2026 - 18:48:10 EST


On Fri, 2026-10-02 at 12:26 +0200, Rodolfo Giometti wrote:
>  
> > So I think we do need it, and my inclination is to hold off on enabling
> > CONFIG_NTP_PPS for tickless kernels until we do. But I'll defer to your
> > preference. If you want to merge it sooner on the basis that with a
> > 1PPS signal the system doesn't get to sleep for long *anyway*, I can do
> > another test run with just patches 1-4.
> >
>
> Yes, please do that run. This patch changes what PPS_FETCH returns to
> userspace, so it has to wait for the chrony and ntpd people anyway; if
> 1-4 alone are good enough at 1PPS I'd rather not tie the tickless
> enablement to it.

https://david.woodhou.se/ntptest-r64/rodolfo-14-tickless-1hz/

Fairly much identical to the full series running tickless, which was
https://david.woodhou.se/ntptest-r64/tickless-1hz/

And not really much worse than the tickful variant
https://david.woodhou.se/ntptest-r64/tickful-1hz/

The ntp_error isn't measured because it's the clean series and most of
the instrumentation is gone. I'll set the 5s pulse version running
overnight.

The series is also tested on four virtual machines on the same host,
tickful and tickless, patches vs. baseline. You can see the tickless
baseline wobble when the actual frequency changes, while the other
three remain stable. You can also see ntp_error on both baseline
kernels spiking during the initial sync.
https://david.woodhou.se/ntptest-virt/

Attachment: smime.p7s
Description: S/MIME cryptographic signature