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

[David Woodhouse]

On Wed, 2026-09-30 at 15:05 +0100, David Woodhouse wrote:
> Just for fun, I've also implemented the code to use the entry.S
> timestamp in pps_gpio_irq_hardirq() (when it eventually gets to run, 4-
> 6µs later). It's been running for an hour now on the the previous worst
> case (5s, tickless). The per-minute average phase offset is around 10-
> 20ns, max mostly around 100-200ns. So the jitter is basically gone. But
> I don't think we're ever going to be allowed to do it that way in
> entry.S but the *hardware-captured* stamps will want the same handling,
> so I wanted to prototype it anyway.

Works quite nicely.

https://david.woodhou.se/ntptest-r64/backdate-tickless-5s/
https://david.woodhou.se/ntptest-r64/backdate-tickful-1hz/

Compare the pulse arrival phase charts of those two with *any* of the
four results in the first 2x2 grid. It's beautiful :)

But the arch maintainers will hunt us down and hurt us if we seriously
try to sample the counter in the exception vector in entry.S.

Interestingly, that ADSR pattern in the frequency chart — that was seen
in all of the other four — doesn't seem to be present here.

I think I've diagnosed it as a beat between my data dump every minute,
and the start of the 256s pps_shift interval.

The data collection causes a group of late pulses, one of which ends up
in freq_norm.nsec and corrupts the current interval by, say,
4.5µs/256s ≈ 17.6 ppb, followed by the *next* interval going in the
opposite direction. That's the 0.02ppm swings we see in the charts.

We don't actually do *any* filtering. Even pps_phase_filter_get() is
just using the first sample, with a comment:

	/* TODO: test various filters */

Looking closer at the actual captures, even Mills's median-of-three
wouldn't save us here when two of the three pulses are outliers. We'd
want an ongoing frequency estimation.

But that's definitely a problem for another day.

I'm intrigued that the pulse latencies introduced by the data dump are
fixed by the entry.S timestamp hack though; that implies they're not
IRQs being disabled, they're additional latency between the exception
and the PPS IRQ handler.

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