Re: [RFC PATCH 1/4] timekeeping: Remove xtime_remainder from ntp_error accumulation

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2168 bytes --]

On Tue, 2026-05-19 at 14:54 -0700, John Stultz wrote:
> 
> > By simply adding ntp_interval and then subtracting the correct current
> > value of xtime_interval, logarithmic_accumulation doesn't *need* a
> > separate variable which tracks that delta. I don't quite understand why
> > it ever did add it in the first place.
> 
> Again, it's due to the error caused by the granularity of the
> clocksource (against the HZ interval).  That initial delta will
> otherwise cause an accurate clock to get erroniously steered either
> faster or slower when no NTP adjustments being made.  The subtracting
> of that remainder is just trying to compensate for this base error.

I must be confused. We *are* subtracting that remainder, not ignoring
it.

The value of xtime_remainder was (tick_length - xtime_interval). It's
the discrepancy between the distance we *want* the clock to move in a
single tick, and the distance it *does* move in a single tick at a
given value of 'mult'.

So we add tick_length, and we subtract xtime_interval. Thus adjusting
ntp_error by the difference between them.

I don't understand why the old code was then *also* subtracting a stale
value of xtime_remainder which had been calculated at boot time.

Am I missing something here? 

I've updated the commit message:
https://git.infradead.org/?p=users/dwmw2/linux.git;a=commitdiff;h=459ebaef612

> Now, it is imperfect because it's a constant adjustment and not
> proportioned to the NTP adjustments that might be later made.
> 
> And clearly there is some issue as you're having problems with it
> using a fine-grained clocksource like the TSC where it really
> shouldn't be a major factor.

None of it matters if you have NTP running and constantly re-adjusting
your clock. You can have a +50PPM drift through errors in the tracking,
and NTP will just assume your oscillator is running 50PPM fast and
adjust accordingly.

But when you set the kernel to follow a precise y=mx+c line for the TSC
to real time conversion and *expect* it to do as it's told while
tracking the divergence to the nanosecond... all counters are course-
grained :)



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]