[time-nuts] Raspberry Pi NTP server

[Tim S]

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