[time-nuts] Re: PPS latency? User vs kernel mode

Jürgen Appel jap at dfm.dk
Sun Dec 12 21:23:54 UTC 2021


Hej, 

On Sunday, 12 December 2021 02.48.53 CET Trent Piepho wrote:

> 3. The jitter in the latency of the timestamp's creation after the pulse.
 
> Of these, I think it's safe to assume that 3 is by far the greatest.  And
> at the very least we get an upper bound for that error.
 
> I think you can find some graphs I made in the list archives.  Switching
> from kernel GPIO PPS timestamping to a kernel driver for a hardware
> timestamper was a vast improvement.  I didn't even bother with userspace
> timestamping, it would surely be far worse than kernel mode, having all the
> same sources of error kernel mode does plus several significant other
> sources.

I have given up on using Raspberry Pi for time-stamping external signals:

I also tried using pps-gpio, but with a graphical user interface present, I 
never managed to limit the worst case timing jitter to below 500 µs reliably.
Especially starting up a Firefox-instance and playing a youtube video provoked 
excessive delays and non-mask-able interrupts. Without a graphical interface, 
these events were much more rare.

I recall, I tried also to limit timing relevant tasks to a separate CPU core 
(this helped a bit, but not really enough), and I am not completely sure 
whether fiddling around with the timer IRQ registers of the interrupt 
controller really disabled all timer IRQs on that core completely, I just 
remember that the documentation on how to write the correct dts-files for 
doing so was close to non-existent, so I might have done that incorrectly...

Without a hardware time stamper for inputs and a programmable hardware timer 
for outputs, I would not trust the RPi for timing purposes.
 
Cheers,
	Jürgen




More information about the Time-nuts_lists.febo.com mailing list