On Mon, Jul 13, 2020 at 8:54 AM Petr Titěra <petr@titera.eu> wrote: > > 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). Looking at the UHCI specification, for USB 1.1 HCIs, while there poll rate is fixed at about 1 ms, it is possible to tweak it slightly via the start of frame modify register. If one is measuring a PPS, then the pulses are not random. It's possible to try to align the USB frames with the PPS and do quite a bit better than just a 1 msec poll rate would do at random. Certainly would be hard to fit this into the software stack. And I don't see this ability in the EHCI spec, though I'm certainly no expert with USB HCI drivers, so perhaps it's gone now because no one could figure out how to use it.

Is there any way for a USB device to synchronise with the CPU clock (perhaps via the USB framing) so that a special-purpose device could timestamp the PPS occurrence with respect to CPU time ? On Mon, Jul 13, 2020 at 9:51 PM Trent Piepho <tpiepho@gmail.com> wrote: > On Mon, Jul 13, 2020 at 8:54 AM Petr Titěra <petr@titera.eu> wrote: > > > > 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). > > Looking at the UHCI specification, for USB 1.1 HCIs, while there poll > rate is fixed at about 1 ms, it is possible to tweak it slightly via > the start of frame modify register. > > If one is measuring a PPS, then the pulses are not random. It's > possible to try to align the USB frames with the PPS and do quite a > bit better than just a 1 msec poll rate would do at random. Certainly > would be hard to fit this into the software stack. And I don't see > this ability in the EHCI spec, though I'm certainly no expert with USB > HCI drivers, so perhaps it's gone now because no one could figure out > how to use it. > > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. >

On 13.07.2020 22:35, Steven Sommars wrote: > Petr, > > Is the variance plot based on PPS timestamps, or on NTP's smoothing of the > timestamps? > It was based on PPS as reported by kernel. NTP was running at that time so the results could be off a little. I've monitored computer with similar setup for a while with NTP off (I could not stop NTP on computer in question as it is production NTP server). Attached are two files. Firs shows you overall offset between system clock and PPS signal from GPS as reported by kernel. You can see that computer in question does not have very stable clock so offset starts to deteriorate quite fast. Second is detail of chart above where you can see that peak to peak offset change is about 125-150microseconds. Petr > Have you measured the offset? > > > On Mon, Jul 13, 2020 at 10:54 AM Petr Titěra <petr@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@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@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@lists.febo.com > To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. >