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

[David Woodhouse]

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.
> 
> > 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?

Ok, I have the series in the shape I want to test it now. I got caught
up in more side quests around minimising ntp_error, which aren't
*strictly* around hardpps or snapshots at all but it was annoying me.

https://git.infradead.org/?p=users/dwmw2/linux.git;a=shortlog;h=refs/heads/timekeeping
now has:

 • timekeeping: Allow tick_length changes to apply mid-tick
   (reduce a fairly gratuitous cause of ntp_error accumulation, when
    we *account* for a rate change before it actually takes effect)

 • timekeeping: Apply extrapolated ntp_error to clock snapshots
   (you know this one; as discussed maybe it'll shift to later)

 • timekeeping: Bound idle sleep while a phase slew is in flight
   (even standard adjtime() was hosed for tickless and would keep
    applying 500µs/s skew the whole time the system slept)

 • timekeeping: Reinstate proportional correction of ntp_error
   (because once I fix the above, we *can*)

 • ntp: Recalculate skew_delta when the phase offset changes
   (another gratuitous cause of ntp_error accumulation. If time_offset
    goes away *while* we're skewing towards it, the continued skew
    for the rest of the second is unwanted and goes to ntp_error.
    Just... stop skewing!)

 • arm64: Support inlined clocksource reads for the arch counter
   (this seems like an oversight)

 • timekeeping: Read the counter as early as possible in ktime_get_snapshot_id()
   (as I said, those 20ns are in the noise... but you can have them
    back anyway)

 • pps: Drop the !NO_HZ_COMMON dependency from NTP_PPS
   (Really, it isn't needed. This is working)

 • pps: Always use ktime_get_snapshot_id() for pps_get_ts()
   (I think I mostly eliminated ntp_error as a significant source of
    discrepancies now, but this is still the right thing to do for
    precision)

And then we get into the get/set reference stuff for vmclock which is a
different RFC series of its own, and mostly comes along for the ride as
I rewrite the underlying timekeeping branch, although I do plan to redo
the "no independent reference" vmclock unit test.

 • timekeeping: Add absolute reference for feed-forward clock discipline
 • ptp_vmclock: Feed reference to timekeeping for feed-forward discipline
 • kernel/time: Add /dev/vmclock_host miscdev
 • [DO NOT MERGE] ptp: ptp_vmclock: Add simulated 1PPS support
 • [TEST HACKS] bench instrumentation for R64 PPS soak

The tests are now running on the BPi-R64.

First, full nohz idle with 5s pulses. It was idle for 3,4,5 seconds at
a time, converged within the first minute, ntp_error remained in double
digit nanoseconds, PPS pulses landing on average within ±150ns of the
second, with occasional 4-6µs interrupt latency excursions. The
adjtimex jitter estimation mostly sat at 0-5ns once converged.
https://david.woodhou.se/ntptest-r64/tickless-5s/

Same nohz idle setup with 1s pulses, ntp_error unsurprisingly much
lower, pulse phase also much tighter. Possibly due to not entering
lower power states?
https://david.woodhou.se/ntptest-r64/tickless-1hz/

I don't much like the shape of the frequency charts. There's that weird
pattern every 256s on the tickless-5s one which reminds me of the ADSR
waveform on a 1980s SID sound chip, and a similar shape with a period
of about half an hour in the 1Hz test. But I don't think that's related
to the *tickless* part at all. My friend has theories but it's far too
late for me to properly follow and sanity-check them tonight.

Running the tickful 1hz test now...

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