PPS capture latency: polling vs interrupt, same pulse

BPI-R64 (Cortex-A53 @ 1.35GHz, 12.5MHz arch counter), u-blox GNSS 1Hz timepulse. A differential measurement: for every pulse, CPU1 busy-polls the GPIO data register directly (~480ns per MMIO read, counter reads bracketing the detecting read) while CPU0 takes the EINT interrupt with the arch counter value captured at exception entry (entry.S) and again in the pps-gpio hardirq handler. All three captures are raw counter values for the same physical edge, so the pulse's own timing and the pin's input path are common-mode; the deltas isolate the capture mechanisms. The clock was free-running (no hardpps, no NTP) — nothing disciplined, nothing to perturb.

Run on a live Fedora 44 system (full userspace), not an idle test bench. Load segments: a dnf upgrade (network, mmc I/O, rpm scriptlets) and loops of dracut --force (compression pipeline). cpufreq governor as marked; this SoC has no cpuidle driver (idle = WFI at the governor's frequency).

Delay after the polled edge (ns)

Exclusions: ~1% of load-segment pulses are excluded where the poll shows the entry stamp predating the pulse by more than 800ns. Those are pulses which arrived while CPU0 was already in an exception taken for an earlier interrupt (the timer tick): the interrupt is serviced from that exception without re-entry, so the entry.S stamp belongs to the tick, not the pulse. The error decays at the crystal-vs-GPS beat rate (~110 ticks/pulse at +8.6ppm) and recurs every ~467s (HZ=250), matching observation. A production entry.S backdate needs a sanity bound against the handler-time snapshot to reject these; the excluded pulses are listed in the run log.

Distributions

The entry.S body barely moves under load (p50 240–320ns) but grows a smooth heavy tail — there is no knee, so no natural threshold to clip at. The handler timestamp is microseconds at best and its whole body shifts with frequency and load.

Can filtering recover the entry.S tail?

The jitter of the polling method has a physical floor: the edge lands uniformly within one GPIO read period, σ = T/√12 ≈ 140ns for the 480ns direct-MMIO loop (~1.5× that via gpiolib). The loop period stretches ~10–15% under load (bus contention on the MMIO read, visible per-pulse as the bracket width) and with CPU frequency, but that is the poll's entire load sensitivity — it holds the CPU with interrupts off, so a pulse is either captured at floor quality or (if the wake loses the race) simply missed. Its jitter is its floor. The entry.S capture has no such floor — idle, its intrinsic jitter measures below the poll's quantisation — but under load it grows a heavy tail of delayed and mis-attributed stamps.

Method: a smoothed ideal pulse train, built retrospectively from the poll's captures only (leave-one-out local linear fit, ±128 pulses, worst-10% trimmed), plus a short local median of the poll residuals subtracted from both methods to remove crystal thermal wander (strongly autocorrelated, lag-1 r≈0.97 under load: frequency motion the servo tracks, not capture jitter — without this step it inflates both methods' σ several-fold and masks the real comparison). The reference inherits a few tens of ns of the poll's own quantisation, which lands on the entry residuals in quadrature: the construction slightly flatters the poll, not the irq path. Mis-attributed stamps (entry predating the polled edge by >800ns; the tick-shadow episodes above) are gated per-sample — they arrive in runs at the crystal-vs-tick beat, which no fixed-length median survives, but each is individually detectable in a real deployment from the entry→handler gap. A median-of-5 then eats the residual isolated delays:

The poll measures σ ≈ 135–155ns in every segment — load-invariant at its quantisation floor, as the structural argument predicts. The entry.S capture spans σ ≈ 50–70ns (idle, raw — genuinely below the poll's floor) through ≈120ns (moderate load, filtered) to ≈280ns (irq-heavy load, filtered — the dnf tail is dense enough that some of it survives a 5-tap median). So: better than polling when the system is quiet, comparable under moderate load, and ~2× worse under irq-heavy load even after gating and filtering — and it requires the per-sample attribution gate to be usable at all.

The run-structured mis-attribution class would disappear structurally if the counter were stamped per-interrupt at the GIC acknowledge (IAR) read rather than once per exception entry — the dispatch loop can service several interrupts from one exception, and the stamp's granularity is currently coarser than the attribution the hardware provides.

Method notes

• Poll loop: raw readl of the MT7622 GPIO DIN register (no gpiolib in the loop), ~480ns sampling period at 1.35GHz; capture is the midpoint of the counter reads bracketing the detecting read (bracket width p50 ~6 ticks = 480ns, i.e. uncertainty ±240ns).
• entry.S stamp: counter read in the arm64 exception vector into pt_regs; the pps-gpio handler compares it against the spin side's published capture (seqcount-protected) and emits one line per pulse.
• Per-method jitter from a retrospective linear fit of counter-vs-pulse-index (free-running clock, fit absorbs crystal frequency+drift): σ ≈ 150ns for the poll (quantisation-dominated), ≈115ns for entry.S, idle.
• Driver: pps-gpio-spin mode 3 on the r64-bench branch (TEST HACKS, not for merging), kernel 7.3-rc1 + the posted timekeeping fixes.