Re: [RFC PATCH v2 3/8] timekeeping: Clamp time_offset delta to prevent infinite tail

[Miroslav Lichvar <mlichvar@redhat.com>]

On Tue, May 19, 2026 at 02:31:41PM +0100, David Woodhouse wrote:
> On Tue, 2026-05-19 at 15:25 +0200, Miroslav Lichvar wrote:
> > I don't think that is an acceptable change of the filter. The impact
> > could be measured on a sufficiently stable clock.
> > 
> > To me that looks like using a wrong tool for the job.
> 
> I chose 20ns/s because it's fairly much in the noise of the existing
> jitter. The idea here is that there's no change in the initial part of
> the exponential delivery of time_offset, but the long asymptotic tail
> ends up applying a skew per second which is *far* smaller than the
> inter-tick jitter of the output anyway, which seems pointless?

It changes the initial part too. Consider a case where the PLL time
constant is set to 0 and the application is updating the PLL once per
second. ntp_offset_chunk() returns 1/4th of time_offset. If the
NTP/PTP measurements are stable to about 20 nanoseconds, the clock
corrections will be 4 times larger than expected.

By inter-tick jitter you mean the +1/0 multiplier changes? That
can be below 1 nanosecond if the clock is updated frequently enough
and the multiplier is sufficient large.

> Without it, the output basically *never* converges to the desired line.

I think it's not supposed to get to zero. It is expected to be updated
regularly with new measurements.

If the cancellation threshold was based on the time constant and the
time since last update (e.g. 32 seconds for time constant 0), that
would probably make more sense to me.

-- 
Miroslav Lichvar