[time-nuts] Raspberry Pi NTP server

[jimlux]

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.

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.