Re: [PATCH v4 3/4] pps: Always use ktime_get_snapshot_id() for pps_get_ts()

[Miroslav Lichvar <mlichvar@redhat.com>]

On Fri, Oct 02, 2026 at 02:44:41PM +0100, David Woodhouse wrote:
>   ┌──────────────────────────────┬─────┬──────┬──────┬──────┬─────┐
>   │ capture method               │ p50 │  p95 │  p99 │  max │   σ │
>   ├──────────────────────────────┼─────┼──────┼──────┼──────┼─────┤
>   │ pps-gpio (IRQ)               │  84 │ 1206 │ 4013 │ 4889 │ 688 │
>   │ polling, stamp after edge    │ 206 │  536 │  665 │ 1106 │ 286 │
>   │ polling, bracketed counter   │ 206 │  545 │  647 │  811 │ 286 │
>   │ polling, bracketed, raw MMIO │ 135 │  359 │  434 │  564 │ 188 │
>   │ entry.S counter capture      │  46 │  109 │  135 │  206 │  58 │
>   └──────────────────────────────┴─────┴──────┴──────┴──────┴─────┘

The time to read the GPIO heavily depends on the HW. On the MIPS
ar71xx where I was using the polling driver, it was 85 nanoseconds
(the precision logged by the driver when loaded).

> (NB: We should be careful not to forget the common-mode hardware
> latency which could be different for the IRQ paths vs. the polling
> paths. On my list is a test where one CPU polls while the other takes
> the interrupt, so we can compare on the *same* pulse.)

Yes, that is the main advantage of the polling driver that it avoids
all those delays before the actual read of the clock.

Both pps-gpio and pps-gpio-poll can echo the input PPS signal back to
a different GPIO pin, so you could measure how the delays differ with
the two drivers on a scope.

-- 
Miroslav Lichvar