Re: [RFC PATCH v2 2/8] timekeeping: Account for clawback adjustment in ntp_error

[John Stultz]

On Sun, May 17, 2026 at 3:03 PM David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
>
> From: David Woodhouse <dwmw@xxxxxxxxxxxx>
>
> timekeeping_apply_adjustment() modifies xtime_nsec to maintain vDSO
> monotonicity when mult changes:
>
>     xtime_nsec -= offset
>
> This ensures that the time reported to userspace doesn't jump when the
> multiplier is adjusted. However, ntp_error — which tracks the difference
> between intended and actual clock position — was not updated to reflect
> this change.
>
> After a mult change, xtime_nsec has moved but ntp_error still reflects
> the old position. For the normal ±1 dithering this is negligible (the
> adjustments cancel over time), but for larger mult changes — such as
> when an external reference clock sets a new frequency — the one-time
> uncompensated offset is significant (~38ns for a 700-count mult change).
>
> Fix by adjusting ntp_error by the same amount:
>
>     ntp_error += offset << ntp_error_shift
>
> This keeps ntp_error consistent with the actual xtime_nsec position
> after the clawback.
>
> Fixes: 1b1b3e2a3671 ("timekeeping: Rework frequency adjustments to work better w/ nohz")

That doesn't seem to be the right commit. Do you mean dc491596f639 ?

But really, we used to do something like this, but it was removed in
commit c2cda2a5bda9 ("timekeeping/ntp: Don't align NTP frequency
adjustments to ticks").  From the difference in the math it looks like
the previous implementation was maybe adjusting for the next tick
instead of the previous?

Also, since you're re-adding it, could you add a detailed rationale to
the comment in timekeeping_apply_adjustment()? (It had long been on my
todo, but by the time I started adding the commits the details had
faded and I never got the time to re-derive the math.)

Miroslav's review and input here would also be good.

thanks
-john