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

[Rodolfo Giometti]

On 01/10/2026 15:14, Miroslav Lichvar wrote:
> On Mon, Sep 28, 2026 at 09:58:02AM +0200, Rodolfo Giometti wrote:
>> On Sat, 2026-09-26 at 21:38 +0100, David Woodhouse wrote:
>>> So yes, the specific code path you're looking at *does* get slightly
>>> longer (50ns to the counter read instead of 30ns).
>> [...]
>>> However, they are *entirely* in the noise, as there's about 600 ns of
>>> hardware and 2-4 *microseconds* of software latency before we even get
>>> there.
>>
>> Thanks for measuring it, and on real hardware with a real edge. That
>> answers my concern: ~20 ns of constant cost against microseconds of
>> latency upstream of the handler is not something PPS can see, and
>> trading it for the removal of a non-constant error is the right
>> trade.
> 
> FWIW, there are some polling versions of the pps-gpio driver (out of
> tree), which provide much more stable measurements by trading
> interrupts for higher CPU use and where this additional delay might be
> visible.
>

If polling gives that much better stability, I'd be glad to have it in
drivers/pps/clients, as a mode of pps-gpio or as a client of its own.
Its timestamping needs would then be part of the discussion about the
timestamping interface started in the 2/4 thread.

Do you see the extra delay there as a shift of the offset or as more
jitter?

Ciao,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@xxxxxxxxxxxx
Linux Device Driver                          giometti@xxxxxxxx
Embedded Systems                     phone:  +39 349 2432127
UNIX programming