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

[Miroslav Lichvar]

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.

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()?

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?

-- 
Miroslav Lichvar