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

[David Woodhouse]

On Wed, 2026-09-30 at 14:57 +0200, Rodolfo Giometti wrote:
> Hi David,
> 
> On 30/09/2026 12:37, David Woodhouse wrote:
> > Three parts of the 2x2 grid are now at
> >  • https://david.woodhou.se/ntptest-r64/tickful-1hz/
> >  • https://david.woodhou.se/ntptest-r64/tickless-1hz/
> >  • https://david.woodhou.se/ntptest-r64/tickless-5s/
> > 
> > The fourth is running now, about 90 minutes in. After which I might
> > play with that IRQF_HWTIMESTAMP thing, because they're *all* seeing a
> > bunch of late pulses (and the tickless ones are doing all the
> > timekeeping catchup before they even capture the pulse timestamp, some
> > of which gets hidden as common mode latency):
> > 
> >   ┌────────────────┬────────┬─────────┬─────────┬────────┐
> >   │      cell      │  p50   │   p95   │   p99   │ >3 µs  │
> >   ├────────────────┼────────┼─────────┼─────────┼────────┤
> >   │ tickless, 5 s  │ 728 ns │ 4188 ns │ 4847 ns │ 14.5 % │
> >   ├────────────────┼────────┼─────────┼─────────┼────────┤
> >   │ tickless, 1 Hz │ 294 ns │ 2258 ns │ 4837 ns │ 3.6 %  │
> >   ├────────────────┼────────┼─────────┼─────────┼────────┤
> >   │ tickful, 1 Hz  │ 84 ns  │ 1206 ns │ 4012 ns │ 2.0 %  │
> >   └────────────────┴────────┴─────────┴─────────┴────────┘
> > 
> > But ultimately, the hardpps discipline appears to be working fine with
> > full nohz idle, even when we dial down the pulse *itself* to 0.2Hz to
> > actually let the box sleep for 5s at a time.
> 
> Thanks for running the whole grid.
> 
> Could you put these numbers, with the fourth cell once it is done, in
> the commit message of 2/4? They show both that hardpps works on a
> tickless kernel and what it costs in timestamp latency, which is what
> someone enabling NTP_PPS there will want to know.

Ack. I've still got a few more passes to do for cosmetics, and working
out precisely how to order things (including putting 'use
ktime_get_snapshot_id() for pps_get_ts()' before 'Apply extrapolated
ntp_error', qv).

I think it ends up as a timekeeping series which can be posted
immediately, and the rest is held back for a future posting when it can
identify specific commit IDs for the dependencies.

I also realised that all four runs were capturing the actual IRQ
handler latency — from entry.S to pps_gpio_irq_hardirq(). With the
standard 1Hz PPS it's 2-3µs in the tickful kernels, 4-5µs in tickless.
I've added the distribution chart and CDF to all four result pages.

So: With the ntp_error fixes in the earlier part of the series which
could be posted as bugfixes today, ntp_error itself is completely in
the *noise* for PPS by some orders of magnitude, compared with the
latency of the IRQ handling path itself. Which means I think we can
actually enable PPS for tickless kernels without depending on the
'Apply extrapolated ntp_error' patch at all.

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.

> At this point it could be fine for me, but before acking I'd like to
> hear from the userland side, Miroslav for chrony and the ntpd folks,
> since the change in ts_real is theirs to judge.

Yep. I think that one wants to go under separate cover and be properly
considered, after the prior timekeeping *fixes*.

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