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 <[email protected]> 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 -- [email protected] > > To unsubscribe, go to > > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > > and follow the instructions there. > > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. > _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
