[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