[time-nuts] Raspberry Pi NTP server

[Petr Titěra]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: FTDI232RL.png
Type: image/png
Size: 66346 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20200713/c4da4aed/attachment.png>