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

[Trent Piepho]

What I did was measure the phase offset of the PPS timestamps in Linux,
after ntp has locked the clock to the PPS.  I think would be made up of
three main sources of error:

1. The phase offset in the PPS signal itself.
2. The error in the Linux clock doing the timestamping, over a tau of 1
second.
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 don't think any of the RPi boards have a SoC with hardware timestamp.
They might have IEEE1588 hardware in the ethernet PHY, but it seems
Broadcom won't release docs to enable support for that.  So the best you
can do without custom hardware would be the pps-gpio module.  This looks
quite easy to setup, with dt-overlays already created.  Just adding:

dtoverlay=pps-gpio,gpiopin=4

Should create a pps device on gpio pin 4 that shows up as /dev/pps0 and can
be used directly by e.g. chrony.  There's a ntp-like algorithm in the
kernel that can be used to sync the kernel clock to a PPS without using
ntpd or chrony or anything in userspace.   It needs to be enabled the
kernel config and then turned on via adjtimex() calls.

On Sat, Dec 11, 2021 at 4:01 PM Adam Space <time.isanapp at gmail.com> wrote:

> I have a PPS with Raspberry Pi setup going. Of course, in terms of
> precision, it's quite good (for me it's as good as I'd ever care for), and
> for accuracy it's quite good too. Although I guess the problem is, I don't
> really know how good the accuracy is, nor am I sure how I would go about
> finding out.
>
> The only factor here would be a delay between the PPS signal and the
> processing in the Pi. I am not using kernel mode right now, which I assume
> makes this even worse. Nonetheless, it is certainly no more than one or two
> ms. When I run ntp with several other peers, you can't tell much of a
> difference. The accuracy limits of NTP are greater than the potential delay
> introduced by the processing of the PPS signal, so even running NTP with a
> lot of peers and averaging over long periods of time doesn't give much info
> on this. (Perhaps if I ran it long enough I could get the mean offset, but
> I think the uncertainty on this value would be larger than the value
> itself).
>
> I am curious what other folks with this type of set-up have done. Just
> leave it at that and accept that there's some unknown latency? Or perhaps
> the latency is on the order of microseconds, in which case it's not really
> a big deal for me.
>
> With regards to kernel mode, I was looking to give it a try. However, the
> guides I've found on this, some posted several years ago on this list, are
> pretty outdated. If someone has a suggestion for this, I'm interested in
> hearing it. Also, my Raspberry Pi is relatively new, running Bullseye, if
> that matters.
>
> Adam
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe send
> an email to time-nuts-leave at lists.febo.com
> To unsubscribe, go to and follow the instructions there.
>