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

[Adam Space]

I guess I didn't include enough details in my original post. I am using the
pps-gpio module--at least as far as I can tell. I have the PPS signal
showing up in /dev/pps0, so that should be working fine right? I assume
that is what NTP is using; otherwise I have no idea where it'd be getting
the PPS signal from.

I am using NTP version 4.2.8p13 right now. Is it worth switching to chrony,
or is this version of NTP making use of the pps-gpio module?

On Sat, Dec 11, 2021 at 9:43 PM Trent Piepho <tpiepho at gmail.com> wrote:

> 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.
> >
> _______________________________________________
> 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.
>