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

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2874 bytes --]

On Fri, 2026-10-02 at 13:29 +0100, David Woodhouse wrote:
> 
> I think the remaining jitter is largely due to the time it takes, in
> the "tight" polling loop, to call gpio_read(). That's twice what I
> estimated — it's 600ns. I'm running a quick test of reading the MMIO
> directly in the loop... even that is still about 400ns on this
> hardware, which isn't going to move the needle very much either.

Hah, I should stop predicting results before I have them. I'm clearly
not very prescient. Spinning on the MMIO (the GPIO wait_for_edge()
method idea) makes more of a difference than I thought (~30% off every
column brings us down to only 3× the entry.S capture):

  ┌──────────────────────────────┬─────┬──────┬──────┬──────┬─────┐
  │ 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 │
  └──────────────────────────────┴─────┴──────┴──────┴──────┴─────┘

(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.)

In the same order (new one is 'spin2'):

 • https://david.woodhou.se/ntptest-r64/tickful-1hz/
 • https://david.woodhou.se/ntptest-r64/spin0-tickful-1hz/
 • https://david.woodhou.se/ntptest-r64/spin1-tickless-1hz/
 • https://david.woodhou.se/ntptest-r64/spin2-tickless-1hz/
 • https://david.woodhou.se/ntptest-r64/backdate-tickful-1hz/

The thing I mentioned about throwing away samples with the wider
brackets didn't survive the longer test; the buckets end up fairly much
identical:
  bracket=2 (n=468):   p50 134  p95 350  p99 472  p100 564 
  bracket=3 (n=1352):  p50 137  p95 363  p99 430  p100 488 

I only let 'spin2' run for 90 minutes, which is less than some of the
other overnight runs but should be sufficient. The board is now doing
the test requested in
https://lore.kernel.org/all/7274f4ef-edec-4282-9c92-b6f7918b8320@enneenne.com/

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6179 bytes --]