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 _______________________________________________ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.