Re: [PATCH v4 2/4] pps: Drop the !NO_HZ_COMMON dependency from NTP_PPS

[David Woodhouse <dwmw2@infradead.org>]

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

On Tue, 2026-09-29 at 13:48 +0200, Rodolfo Giometti wrote:
> Hi David,
> 
> On 29/09/2026 11:32, David Woodhouse wrote:
> > When second_overflow() is delivering skew, timekeeping_max_deferment()
> > should trigger a wakeup at the end of the second to ensure that the
> > skew gets recalculated — rather than leaving it active indefinitely.
> 
> Please put this fix in the series before 2/4, as for the tick_length
> one.

Yep.

I've vacillated a bit about ntp_error: should we compensate for it
(patch 1/4), should we *eliminate* it (as I mentioned we can again now
I added the wakeup), and/or should we avoid the situations where it
even *accumulates* in large quantities (e.g. time_offset being changed
mid-second while skew is still running, so the now-unwanted skew has
nowhere to go but ntp_error).

I have come to the conclusion that all three can be true
simultaneously, and I have patches for each :)

> > So the results at https://david.woodhou.se/ntptest-r64/tickless/ need
> > to be redone, but you can take a look and shout if you want me to
> > change what I'm capturing or how I'm doing it.
> 
> What you capture is fine for me: the adjtimex state (offset, jitter,
> stabil, errcnt) plus the per-pulse phase are what I wanted to see.
> 
> Two questions for the rerun:
> 
> - wouldn't it be better to also have the tickful baseline with the same
>    board, the same GPS and the same pulse period, so the numbers can be
>    compared directly?
> 
> - since typical PPS sources deliver 1 Hz, don't you think it would be
>    better to also do one run with the timepulse at 1 Hz?

That full 2x2 matrix is on the list, but I only have one board. :)

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