Re: [PATCH 4/5] timekeeping: Reinstate proportional correction of ntp_error

[David Woodhouse]

On 5 October 2026 12:04:53 CEST, Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:
>On Thu, Oct 01, 2026 at 09:21:33PM +0100, David Woodhouse wrote:
>> From: David Woodhouse <dwmw@xxxxxxxxxxxx>
>> 
>> The ±1 mult dithering is sufficient to keep ntp_error at zero once
>> it's already there, but it doesn't do much to reduce it once any
>> significant ntp_error has accumulated (e.g. from frequency or phase
>> adjustments) — it can typically only drain single-digit nanoseconds
>> per second. Commit dc491596f639 ("timekeeping: Rework frequency
>> adjustments to work better w/ nohz") removed a larger skew because in
>> a tickless kernel, it would remain in effect for a full idle period
>> and overshoot. Now that timekeeping_max_deferment() ensures that the
>> system wakes at the top of the second when skew is active, the
>> correction can be reinstated. If ntp_error exceeds an amount that a
>> single ±1 change to mult can drain within a minute, add an
>> additional bias to mult to close the gap.
>
>The dithering is switching between an adjustment of +0 and +1, there
>is no -1. The time to drain depends on the direction. If the mult
>division has no remainder, it's infinite for +0. I think that's ok for
>this change, but the message and comment could be more clear.
>
>A faster correction creates a larger frequency error.

Right. I did consider making the threshold depend on the difference from the nearest integer in the direction of ntp_error, and how long it would actually take to eliminate using the natural dithering. But in the end I think I dropped that complexity from the version I posted.

I did also ponder making it truly ±1 from the base mult, instead of just +0/+1.


>Is this patch considered a requirement of the one adding the ntp_error
>correction to PPS and other timestamps to avoid larger inconsistencies
>with clock_gettime()?

No, I don't think so. There are a few phases of the ntp_error fixes I've been looking at.

 - fixing the misaccounting (already merged)
 - reducing the (known) genuine cases where it accumulates (patches 1-2 here)
 - eliminating it once it does accumulate (patches 3-4 here)
 - subtracting it to "correct" the snapshot (patch 5 posted as DNM here)

The three parts I'm posting here are complementary, and the snapshot correction doesn't *require* the previous patches (apart from the bug fixes already merged).

If anything, it's the opposite: driving ntp_error down to only what's temporarily introduced by tickless drift will raise the question of if we even need to *bother* with the final patch (I think probably yes, but will be doing a bunch more testing on tickless kernels once the dust settles).

>I'm wondering if this duality of the clock wrt the way it's read
>couldn't cause any issues. Any chance there could be a new clock ID
>for applications to do clock_gettime() with the ntp_error corrected as
>well?

In theory, sure, we could plumb it all the way to the vDSO. I think we would want to have a very compelling use case for that though.

I'm slightly more inclined to let such userspace use the clock_get_reference() that Thomas and I talked about, and convert counter values to time at their leisure.

And ultimately, perhaps, just calibrate the *counter* directly without any of the feedback loop that adjtimex() + clock_gettime() gives you, then *tell* the kernel the result with clock_set_reference()...