[time-nuts] Raspberry Pi NTP server

Sat Jul 11 20:30:51 UTC 2020

Using GPIO with an RPi is a good direction, of course.   That wasn't my
question.   Some data may help explain.
Configuration =
    RPi4 (raspbian buster)
    Uputronics RPi GPS board (includes PPS) connected to GPIO pins.   This
is the time of day source for the RPi4.  (via GPSD+chrony).
    Navisys USB GR701 (includes PPS and   Integrated serial->USB
conversion). Contains integrated Prolific Technology, Inc. PL2303

The observed PPS variation on the Uputronics PPS is a few microseconds.
(ppstest was used for measurements).  Using a PPS to drive NTP's computer
clock disciplining, which is in turn used to measure the same PPS makes for
a dubious circular measurement.    It is comforting though to see that the
variance is in the ~1-3 microsecond range.   One must also add Trent's
interrupt latency measurement (3 microseconds).   With the GPIO connection
the RPi time base should be within say 10 microseconds of UTC.

The USB-connected Navisys fares worse.
[image: image.png]
By the time the PPS reaches the OS there is about 1 msec of variance with
an average offset of a bit over 0.6 msec.
I suspect the 1 msec USB polling is the largest latency contributor, though
there are other sources as mentioned by Tim.
I'd like to reduce the USB polling contribution by polling at 125
microseconds as the Linux PPS folks suggest
(http://linuxpps.org/doku.php/technical_information)    Would an FTDI-based
USB convertor do the trick?

Why bother with GPS/USB?  Sometimes I use laptops.  Few laptops today
directly support PPS/serial.
I just checked with Dell and found zero laptops with native RS232.

On Fri, Jul 10, 2020 at 2:17 PM Tim S <tim.strommen at gmail.com> wrote:

> I believe the issue is arising from the understanding of "what" is being
> interrupted.
>
> When a UART or GPIO is triggering an interrupt - for the UART it's a FIFO
> notice that data is available to be pulled out, for the GPIO it's
> notification of a state change (and optionally, a specific state change:
> high-low/low-high).
>
> When a USB PHY trips an interrupt it's to indicate that carrier data is
> ready, or for a USB MAC that burst blocks over the link are being decoded.
> There is an intermediate step between the USB carrier data being
> received/decoded, and being interpreted by the driver as a specific type of
> data - and the time that it is made available to the host OS.  Because that
> is handled in the driver, it is subject to all of the other host OS
> interrupts - so timing is not deterministic for the USB driver.
>
> The differences here are key.
>
> A 1PPS wired to a GPIO interrupt for the specific pulse edge (rising) will
> be associated with a very precise correlation to an interrupt vs system
> tick value.
>
> A UART time edge (watching the seconds value increment) will be subject to
> the rate at which bytes are transferred out of the UART FIFO, then math is
> done to detect the second transition edge.
>
> A USB-to-Serial converter will first encode the bytes and status pin states
> into a payload compliant with USB trafic standards, transmit that data to a
> USB Host (PHY/MAC) device, which  triggers and interrupt for the driver
> to decode the data back into meaningful data for the host, then forwards
> virtual interrupt triggers to the tasks which are watching the states and
> bytes.  Everything on the host-side is subject to system overhead, USB
> driver optimization, etc. and is thus variable.  The host-side backend of
> the USB transfer is where your variability is coming from IMHO.
>
> This is why the recommendation is to use direct (not bridged/adapted)
> UART+GPIO from most RPi NTP server projects.  The timing is most critical
> to the 1PPS edge, so the most direct correlation possible to a tick value
> in the OS is the goal.  There is nothing saying that the NMEA messages must
> have such low latency however - in general they merely must arrive in time
> before the next 1PPS, so USB serial is fine for that traffic.
>
> -Tim
>
> On Thu, Jul 9, 2020 at 9:00 AM <time-nuts-request at lists.febo.com> wrote:
>
> > Message: 4
> > Date: Wed, 8 Jul 2020 15:02:49 -0500
> > From: Steven Sommars <stevesommarsntp at gmail.com>
> > To: Discussion of precise time and frequency measurement
> >         <time-nuts at lists.febo.com>
> > Subject: Re: [time-nuts] Raspberry Pi NTP server
> > Message-ID:
> >         <CAD4huA65673=wrNAM9dUrqznCWKdc_x=LeYfUsVThj=-
> > aTzYLQ at mail.gmail.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > My RPi4 (Raspbian Buster) has a GPS+PPS/USB.  Serial->USB uses Prolific
> > PL2303, which supports USB 2.0
> > The PPS jitter is 1 msec (e.g., using ppstest).  lsusb -v shows:
> >
> > Bus 001 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial
> > Port
> >         bInterval               1
> >
> > which means 1 msec polling of the PPS signal.   I've been unable to poll
> > more frequently, that seems to require driver changes.
> > Petr, what polling rate do you see?    Has anyone been able to poll USB @
> > 125  ?sec on a stock RPi?
> >
> > With the 1 ms polling the PPS reaches the OS between 0 and 1 ms late, in
> an
> > unpredictable pattern.    Although the PPS jitter is 1 msec, ntpd/chrony
> on
> > my RPi4 typically reports low dispersion:  50-150  ?sec.  The zero-mean
> > assumption Achim mentioned is unlikely to be valid. Running chrony +
> > GPS+PPS/USB I see a ~640?sec offset compared to a GPS+PPS directly
> > connected to the GPIO pins.  That offset will fluctuate, of course.
> >
> > Steve Sommars
> >
> >
> >
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 40864 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20200711/2ed29c5c/attachment.png>