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

[David Woodhouse]

On Tue, 2026-05-19 at 15:25 +0200, Miroslav Lichvar wrote:
> On Sun, May 17, 2026 at 10:25:40PM +0100, David Woodhouse wrote:
> > From: David Woodhouse <dwmw@xxxxxxxxxxxx>
> > 
> > ntp_offset_chunk() computes delta as time_offset >> (SHIFT_PLL +
> > time_constant), which exponentially decays toward zero but never
> > reaches it. This means time_offset asymptotically approaches zero
> > without ever completing — the clock never fully converges.
> 
> That's how the NTP PLL was designed to work. It is an infinite impulse
> response filter.
> 
> > Fix by clamping delta:
> >   - Minimum: 20ns/sec (NTP_OFFSET_DELTA_MIN), ensuring the tail
> >     converges in finite time
> 
> 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?

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature