On Mon, 2026-09-28 at 18:41 +0200, Rodolfo Giometti wrote:
> On Mon, 2026-09-28 at 14:37 +0100, David Woodhouse wrote:
> > But I can *simulate* it, by running a virtual machine with vmclock and
> > knowing the precise relationship of counter to real time that I'm
> > *telling* it to discipline against — then checking how it did. Your "no
> > independent reference anywhere" is my "I'm actually testing the part I
> > want to test" :)
> 
> What it cannot show is the thing this patch actually enables: hardpps
> on a tickless kernel driven by a real PPS source, with its jitter, its
> IRQ latency, and the CPU going idle between pulses. If you (or someone
> on Cc) can run it for a while with a GPS PPS on a GPIO and report how
> the offset converges compared with a tickful kernel, that is the test
> I would like to see mentioned in the commit message. If not, please at
> least state there that the validation was done with the simulated 4/4
> pulse only.

Yeah, working on that now. My first soak test on the nohz_full build
didn't have nohz_idle, so it wasn't really very tickless.

Running it again now, it looks a bit better — a test binary in an
initramfs, no network or real system activity. Waking once a minute to
dump stats to the serial port. With HZ=250 it's only waking about 1500
times a minute, and I'm seeing ntp_error p95 21ns, p100 116ns. More
data, and pretty graphs, when I'm confident of the results and have the
A/B testing. I'll get some data on the distribution of the sleep times
too (I'm assuming most of those wakeups come while the serial dump is
running).

The ntp_error being corrected is still two orders of magnitude less
than the jitter on the IRQ, mind you. I think it's even processing the
timekeeping when woken by an the IRQ, before running the PPS IRQ
handler. I'm going to play with that IRQF_HWTIMESTAMP thing I
mentioned, and sample the counter right at the start of the exception
vector. (And again, my endgame here is hardware sampling it before the
CPU even wakes up).