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

[David Woodhouse <dwmw2@infradead.org>]

On 5 October 2026 10:15:01 CEST, Rodolfo Giometti <giometti@enneenne.com> wrote:
>On 03/10/2026 00:47, David Woodhouse wrote:
>> 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/
>
>Thanks, that's convincing: with 1-4 alone tickless at 1Hz looks the
>same as with the full series, so I'm fine with the tickless enablement
>not depending on this patch. :-)
>
>Please put these numbers, and the 5s ones when you have them, in the commit
>message of the patch dropping !NO_HZ_COMMON.

Will do. I'll let these four patches progress at least to the point where they have stable commit IDs before doing so — I don't think there's any rush for the PPS change, as it's been quite a few years already :)

In the meantime since I'm working on the filtering. Mills's median-of-3 helps, but min-of-3 seems to work better for the frequency side, because late pulses are less believable than early ones, yet two late pulses out of three is enough to pollute the median. I won't subject you to stream-of-consciousness testing on those; my test candidates are doing full 24h runs while I'm at LPC this week.

As a parallel thread I'll also look at unconditionally using the existing (non-correcting) ktime_get_snapshot_id() so that we have the corresponding counter values, and an ioctl for reporting those to userspace alongside the ts_real. I am leaning towards using raw counter values even when an offset has been applied to the realtime value, but still vacillating a bit.