Re: [PATCH v4 5/7] timekeeping: Drive time_offset skew via per-tick ntp_error transfer

[David Woodhouse <dwmw2@infradead.org>]

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

On Mon, 2026-05-25 at 14:54 +0100, David Woodhouse wrote:
> 
> @@ -460,9 +486,14 @@ int second_overflow(unsigned int tkid, time64_t secs)
>  	/* Compute the phase adjustment for the next second */
>  	ntpdata->tick_length	 = ntpdata->tick_length_base;
>  
> +	/*
> +	 * Set the per-tick skew rate for the tick code. This is in the
> +	 * same units as tick_length (ns << NTP_SCALE_SHIFT), and is
> +	 * rounded to a multiple of NTP_INTERVAL_FREQ so that the per-tick
> +	 * division in the tick code is exact.
> +	 */
>  	delta			 = ntp_offset_chunk(ntpdata, ntpdata->time_offset);
> -	ntpdata->time_offset	-= delta;
> -	ntpdata->tick_length	+= delta;
> +	ntpdata->skew_delta	 = div_s64(delta, NTP_INTERVAL_FREQ) * NTP_INTERVAL_FREQ;
>  
>  	/* Check PPS signal */
>  	pps_dec_valid(ntpdata);

It turns out the infinite impulse response really *is* infinite because
once time_offset gets low enough that ntp_offset_chunk() returns zero,
that last bit of time_offset is *never* drained.

And rounding down to a multiple of NTP_INTERVAL_FREQ as I do in this
patch, just increases the threshold below which it stops draining.

If I repost this series I'll set skew_delta to ±NTP_INTERVAL_FREQ if it
ends up zero when time_offset isn't. Otherwise I'll do it in a follow-
up.

In practice it barely matters; it's *fractions* of a nanosecond. But
it's annoying :)

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