[time-nuts] Raspberry Pi NTP server

[Steven Sommars]

Petr,

Is the variance plot based on PPS timestamps, or on NTP's smoothing of the
timestamps?

Have you measured the offset?


On Mon, Jul 13, 2020 at 10:54 AM Petr Titěra <petr at titera.eu> wrote:

> On 12.07.2020 3:57, jimlux wrote:
> > On 7/11/20 1:30 PM, Steven Sommars wrote:
> >> 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.
> >>
> >>
> >
> > I would not expect another kind of USB to serial converter to do better.
> > The problem is higher up in the way that Linux handles USB devices. The
> > USB hardware can certainly handle higher rates (and does), but the
> > "software interrupts" as the event travels up the stack limits the
> > timing resolution.
> >
>
> I beg to differ. With correct USB convertor I achieve sub millisecond
> variance (see attached screenshot fro FTDI232RL chip). I get similar
> results on other computers too.
>
> All Prolific  chips I saw claimed to be USB 2.0 Full-speed. That means
> they are polled only once in 1ms and there is no way how to change it
> (poll rate is selected at hardware level).
>
> Petr Titera
>
> > You might want to look into one of the "real time" linux kernels or
> > other similar implementations - they might have "turned some of the
> > knobs" to improve the handling of device data.
> >
> > USB device handling in Linux (and Windows, and Mac OSX) is quite
> > complex, if only because USB itself is quite complex in that it has to
> > support multiple "kinds" of devices with wildly varying properties (HID,
> > Mass Storage, Isochronous data, etc.) - Not to mention all the
> > complexities associated with hot plugging and unplugging and
> > "enumeration" and "power control".
> >
> >
> > You might also want to delve into the handling of USB request Blocks
> > (URBs) which is how Linux handles USB related events.
> >
> >
> https://www.oreilly.com/library/view/linux-device-drivers/0596005903/ch13.html
> >
> >
> > https://www.kernel.org/doc/html/v4.12/driver-api/usb/index.html
> >
> > The above document describes a variety of ways to get at USB devices in
> > non-standard ways, through the USB API.
> >
> >
> > Another interesting alternative might be to modify the low level
> > interrupt handler for your Prolific chip (or whatever you're using) -
> > you could probably snapshot the system timer in the IRQ. But then you're
> > faced with the challenge of propagating that time to where you need it,
> > and hopefully in a way that doesn't break Linux.
> >
> >
> > In any case, your problem is not that it's USB. Your problem is that
> > Linux has some compromises in how it handles USB devices that
> > essentially imposes a 1kHz quantization on it.
> >
> >
> > There is a reason why USB support was late in coming to Linux compared
> > to other devices. And there's a reason why everyone curses at serial
> > interfaces, particularly over USB. Their character at a time behavior
> > fits real well for read() and write() in most OSes, but the ioctl() call
> > tends to be very, very complex. And getting high speed or deterministic
> > behavior is always a challenge.
> >
> > I feel your pain. All of my serial interfaces stopped working when I
> > went from Mavericks to Mojave... I finally got a SiLabs interface
> > working, and one instance of a FTDI device.  The Prolific PL2303, not
> > yet.  I was seriously contemplating making Ethernet to USB interfaces on
> > an Arduino, where there's no OS involved.
> >
> > I have so many pieces of equipment with USB interfaces, all a bit
> > different, all sort of using a serial port model.
> >
> >
> >
> > _______________________________________________
> > 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.
>
> _______________________________________________
> 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.
>