[time-nuts] Raspberry Pi NTP server

[Steven Sommars]

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





On Wed, Jul 8, 2020 at 12:57 PM ASSI <Stromeko at nexgo.de> wrote:

> On Dienstag, 7. Juli 2020 18:27:01 CEST Petr Titěra wrote:
> > Timing on USB need not to be so horrible. Below is stats from my server
> > with GPS connected using FT232H chip (supporting high speed transfers on
> > USB). Yes, the jitter is far greater than on other computer where PPS is
> > connected directly but it is a lot less than that 500microseconds you
> > get with common USB convertors.
> >
> >       remote          refid     st t when poll reach delay offset jitter
> > =======================================================================
> > o127.127.22.0   .PPS.           0 u    7   16  377  0.000 -0.019  0.033
> > *192.168.3.240  .GPSD.          1 u   24   64  377  0.377  0.187  0.026
> > +192.168.3.246  .PPS.           1 u   28   64  377  0.643  0.181  0.028
>
> The reason you're seeing this with the newer FTDI chips that support
> USB2.0
> highspeed rates is that the frame rate got increased 8x for highspeed USB,
> so
> the expected frame jitter is now 125µs when and if the interface as well
> as
> the full protocol stack support and enable it.  But you seem to have
> missed
> the point that Hal was trying to make: The jitter you are going to see has
> deterministic components and some of these can create bias when you try to
> filter with the usual assumption of a stationary zero-mean random
> sampling.
> In other words, you don't necessarily converge to the true time and where
> your
> filter tries to converge varies over time.
>
>
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>
> DIY Stuff:
> http://Synth.Stromeko.net/DIY.html
>
>
>
>
> _______________________________________________
> 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.
>