Re: [time-nuts] Raspberry Pi NTP server
On Wed, Jul 15, 2020 at 7:25 PM jimlux wrote: > > I use teensy boards (pjrc.com) for this kind of thing (Arduino sort of, > but much, much more - much faster processor with more resources, and > physically smaller). > > I've used Teensy 3.1s and 3.2s - but a Teensy LC for $12 might do it. > https://www.pjrc.com/store/teensylc.html > > lots of timers on the chip. You can in fact, run it off an external > clock, although if you change from the native frequency, the USB > interface won't work (but it is conceivably reprogrammable to make it work) > > I mentioned the teensy 4.1 a few weeks ago, interesting because of its IEEE-1588 - capable ethernet hardware. I now see that someone has implemented NTP with a GPS PPS source on the device. Details and measurements at https://forum.pjrc.com/threads/61581-Teensy-4-1-NTP-server ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
This'll be my last chime-in on this topic... The problem here is that the interrupt of 125uSec to check for state change is in software. The 1PPS transition that you'd want to measure the jitter of is in hardware. Doing this experiment would require the same hardware being recommended to to direct HW interrupts - i.e., a system with exposed low-level GPIO pins that directly trip an interrupt in the host OS. I'm not sure if it's being grasped that what is being talked about here is the difference between push and pull. With a low-level GPIO, it is pushing an event into the system when it happens. For USB polling - it is pulling new events in when it has time to check. Think of GPIO like yanking a rope tied to the CPU's wrist every time it wants attention. USB's handler is something like turning the faucet on, and the CPU is checking every once in a while to see if the glass is overflowing before turning off the tap - the USB interrupt handler knows there is something it should pay attention to (starting a watch event poll), but it doesn't control the volume of the glass or the fill rate from the faucet. "...Nope not full, nope not full, nope not full, OMG it's overflowing!..." The big reason this is so variable is that USB is based on sharing PC time. It's designed to let the PC do what it wants for a while then fires an asynchronous interrupt to check state. Conversely and low-level GPIO is designed to forgo the asynchronous interrupt timer and only call when the state changes (and in most platforms, one can configure which state transition to watch for). Tuning a measurement PC with an real-time GPIO will get you down to <=10uSec - which would give you about 4-bits of fractional resolution for the jitter/lag measurement on the 125uSec USB interrupt timer. By hand tuning an embedded computer like a RaspberryPi, so that only the interrupt handler for the 1PPS GPIO runs on one of the four cores - this makes the loop size ridiculously small (only a few instructions). With a short loop size, all it has to do is pause until an interrupt occurs, then when it occurs copy the tick time to a register (stack push), signal a new edge to a thread running on another core (set a flag bit), then go back to the paused state waiting for the next edge. Even with a CPU idle speed of 600MHz, and assuming a very large 4 clocks cycles per instruction (most commands in A72 cores of this nature would be single cycle instructions) - that's a maximum loop interrupt-trigger-to-interrupt-waiting of 6.666nSec. That would be about a bit more than 16-bit counter worth of time to the 125uSec USB interval timer. The topic of idle CPU speeds does remind me of another impact of latency/jitter... not very many PCs are fixed clock by default any more. This can/should be changed on a time-critical/jitter-sensitive machine... -Tim > Date: Wed, 15 Jul 2020 05:59:12 -0700 > From: Hal Murray > To: Trent Piepho > Cc: Discussion of precise time and frequency measurement > , hmur...@megapathdsl.net > Subject: Re: [time-nuts] Raspberry Pi NTP server > Message-ID: > <20200715125912.4e422406...@ip-64-139-1-69.sjc.megapath.net> > Content-Type: text/plain; charset=us-ascii > > > tpie...@gmail.com said: > > It seems like it would not be that hard to get the USB frame sequence > phase > > locked to the system clock. One would need a way to measure the phase > offset > > of the USB S-o-F vs the system clock, and then it's a standard process to > > phase lock, with the necessary control to do this described above. > > The catch is that getting the frame lined up doesn't provide you with any > info > about the offset. (I'm assuming we have something like a RS-232 to USB > setup > with the PPS signal connected to one of the modem control signals - > Carrier > Detect is the most popular.) > > If you have a knob to slew the phase of the USB signal, and things are > stable, > you could move the USB signal so that it is exactly lined up. Then noise > in > the system would make half the samples come up "no" and the other half > come up > "yes". That probably depends on something like the noise being large > relative > to the stability of the system. (You could add artificial noise.) If > things > aren't that stable, you can steer the USB timing back and forth to bracket > the > PPS signal. > > It all seems much simpler to put a counter in the USB device to measure > the > time between the PPS and the poll. That actually sounds like a fun hack. > Does anybody have a favorite dev board with a CPU and USB that would be > appropriate for doing that? > > -- > These are my opinions. I hate spam. > > ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
On 7/15/20 5:59 AM, Hal Murray wrote: tpie...@gmail.com said: It seems like it would not be that hard to get the USB frame sequence phase locked to the system clock. One would need a way to measure the phase offset of the USB S-o-F vs the system clock, and then it's a standard process to phase lock, with the necessary control to do this described above. The catch is that getting the frame lined up doesn't provide you with any info about the offset. (I'm assuming we have something like a RS-232 to USB setup with the PPS signal connected to one of the modem control signals - Carrier Detect is the most popular.) If you have a knob to slew the phase of the USB signal, and things are stable, you could move the USB signal so that it is exactly lined up. Then noise in the system would make half the samples come up "no" and the other half come up "yes". That probably depends on something like the noise being large relative to the stability of the system. (You could add artificial noise.) If things aren't that stable, you can steer the USB timing back and forth to bracket the PPS signal. It all seems much simpler to put a counter in the USB device to measure the time between the PPS and the poll. That actually sounds like a fun hack. Does anybody have a favorite dev board with a CPU and USB that would be appropriate for doing that? I use teensy boards (pjrc.com) for this kind of thing (Arduino sort of, but much, much more - much faster processor with more resources, and physically smaller). I've used Teensy 3.1s and 3.2s - but a Teensy LC for $12 might do it. https://www.pjrc.com/store/teensylc.html lots of timers on the chip. You can in fact, run it off an external clock, although if you change from the native frequency, the USB interface won't work (but it is conceivably reprogrammable to make it work) An Arduino might also do it. Both have serial ports and USB interfaces. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
On 7/15/20 5:16 AM, Petr Titěra wrote: On 15.07.2020 0:13, Trent Piepho wrote: On Mon, Jul 13, 2020 at 4:52 PM Hal Murray wrote: 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 ? It seems maybe this was thought about in USB 1.1. From the UHCI spec: Minor adjustments can be made to this value [ 1-ms frame time] ... This feature permits minor changes to be made to the frame time period, if necessary, to maintain real-time synchronization throughout a USB system. It seems like it would not be that hard to get the USB frame sequence phase locked to the system clock. One would need a way to measure the phase offset of the USB S-o-F vs the system clock, and then it's a standard process to phase lock, with the necessary control to do this described above. I think you can have problems with that. At least in general. Look at this specification of system clock generation chip: https://datasheet.datasheetarchive.com/originals/distributors/Datasheets-DGA19/372682.pdf It seems to two independent PLLs to generate USB clocks and system clocks. Is common frequency source enough to synchronize these two? There are more recent generators which claim that they use one common source for all generated frequencies but generally you can have separate timing of USB and rest of the system. Petr Titera Yeah, but in the case of a USB-Serial dongle, they're not going to use a chip like that. https://www.ftdichip.com/Products/ICs/FT231X.html is a typical simple USB-Serial part It has a single 12 MHz internal clock (see fig 2.1 of datasheet) that's multiplied up to 48 MHz - of course they say nothing about anything else inside the chip. It kind of depends on how they implemented the serial to USB functions - I'm going to guess it's simple software on a microcontroller (since FTDI makes microcontrollers too) and it's unlikely that the software is running an RTOS with multiple threads. More likely, it implements some sort of state machines, or possibly, a "big loop" polling scheme. So I suspect the timing from Serial Port events to USB events is fairly consistent. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
tpie...@gmail.com said: > It seems like it would not be that hard to get the USB frame sequence phase > locked to the system clock. One would need a way to measure the phase offset > of the USB S-o-F vs the system clock, and then it's a standard process to > phase lock, with the necessary control to do this described above. The catch is that getting the frame lined up doesn't provide you with any info about the offset. (I'm assuming we have something like a RS-232 to USB setup with the PPS signal connected to one of the modem control signals - Carrier Detect is the most popular.) If you have a knob to slew the phase of the USB signal, and things are stable, you could move the USB signal so that it is exactly lined up. Then noise in the system would make half the samples come up "no" and the other half come up "yes". That probably depends on something like the noise being large relative to the stability of the system. (You could add artificial noise.) If things aren't that stable, you can steer the USB timing back and forth to bracket the PPS signal. It all seems much simpler to put a counter in the USB device to measure the time between the PPS and the poll. That actually sounds like a fun hack. Does anybody have a favorite dev board with a CPU and USB that would be appropriate for doing that? -- These are my opinions. I hate spam. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
On 15.07.2020 0:13, Trent Piepho wrote: On Mon, Jul 13, 2020 at 4:52 PM Hal Murray wrote: 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 ? It seems maybe this was thought about in USB 1.1. From the UHCI spec: Minor adjustments can be made to this value [ 1-ms frame time] ... This feature permits minor changes to be made to the frame time period, if necessary, to maintain real-time synchronization throughout a USB system. It seems like it would not be that hard to get the USB frame sequence phase locked to the system clock. One would need a way to measure the phase offset of the USB S-o-F vs the system clock, and then it's a standard process to phase lock, with the necessary control to do this described above. I think you can have problems with that. At least in general. Look at this specification of system clock generation chip: https://datasheet.datasheetarchive.com/originals/distributors/Datasheets-DGA19/372682.pdf It seems to two independent PLLs to generate USB clocks and system clocks. Is common frequency source enough to synchronize these two? There are more recent generators which claim that they use one common source for all generated frequencies but generally you can have separate timing of USB and rest of the system. Petr Titera ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
Hi > On Jul 14, 2020, at 6:13 PM, Trent Piepho wrote: > > On Mon, Jul 13, 2020 at 4:52 PM Hal Murray wrote: >>> 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 ? > > It seems maybe this was thought about in USB 1.1. From the UHCI spec: > >Minor adjustments can be made to this value [ 1-ms frame time] > ... This feature permits minor changes to be made to the frame time > period, if necessary, to maintain real-time synchronization throughout > a USB system. > > It seems like it would not be that hard to get the USB frame sequence > phase locked to the system clock. One would need a way to measure the > phase offset of the USB S-o-F vs the system clock, and then it's a > standard process to phase lock, with the necessary control to do this > described above. To make this work, both ends of the USB link would need to “understand” what is going on. With part of the link buried in a USB <-> serial chip, that might not be very easy to do. Bob > > ___ > 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.
Re: [time-nuts] Raspberry Pi NTP server
On Mon, Jul 13, 2020 at 4:52 PM Hal Murray wrote: > > 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 ? It seems maybe this was thought about in USB 1.1. From the UHCI spec: Minor adjustments can be made to this value [ 1-ms frame time] ... This feature permits minor changes to be made to the frame time period, if necessary, to maintain real-time synchronization throughout a USB system. It seems like it would not be that hard to get the USB frame sequence phase locked to the system clock. One would need a way to measure the phase offset of the USB S-o-F vs the system clock, and then it's a standard process to phase lock, with the necessary control to do this described above. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
> 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 ? If you were designing a special purpose device, just add a counter to measure the time from the PPS until the CPU reads the info. Suppose you could control the USB timing. Each sample doesn't give you a number, only a yes/no or rather a before/after. It might work if you ask a bit after you expect the PPS and the next second ask a bit before. The question is how small can you make a "bit". -- These are my opinions. I hate spam. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
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 wrote: > On Mon, Jul 13, 2020 at 8:54 AM Petr Titěra 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. > ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
On Mon, Jul 13, 2020 at 8:54 AM Petr Titěra 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.
Re: [time-nuts] Raspberry Pi NTP server
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 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 > >
Re: [time-nuts] Raspberry Pi NTP server
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 --
Re: [time-nuts] Raspberry Pi NTP server
On Sun, Jul 12, 2020 at 11:51 AM jimlux wrote: > > Is the PPS via USB CTS stamped at interrupt time? or is it stamped > higher up in the stack? > > I started tracing this out, but then decided I'm not going to be writing > Linux USB drivers any time soon, so gave it up. > > I could easily imagine that the interrupt comes in, marks a thread as > "ready to run" and the "oh CTS has changed state" is detected at a > higher level. Best way to see this is to do live tracing. Use perf to turn on event captures with IRQs, context switches, PPS events, USB events. Then in something like Trace Compass you can see the timeline of what is actually happening. The hard IRQ context first, then maybe a context switch into a kernel thread that was made runnable by an action of the irq handler. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
On Sun, Jul 12, 2020 at 5:08 AM Matthias Welwarsky wrote: > > If you think about using an AM3358, there's zero reason to use a GPIO for PPS > input. There are much better options, like the gptimer inputs or the eCAP > engine, which runs on a 200MHz clock and is therefore able to create much more > accurate timestamps. A much better way to go for sure. There would be just the latency of the PPS vs the capture block's clock, plus anything in the logic of that block. All the delays that happen afterward, both just in getting the interrupt to the CPU and also in handling the interrupt in software before a PPS timestamp can be generated, can be subtracted out by using the timer. How much difference does it make? I've actually got data on that, see attached graph. This is for a Cyclone V, but it's very comparable to an AM3358, other than being dual core. The uncorrected jitter histogram is similar to what using a GPIO would give. Though it uses a custom PPS driver, which I wrote to try to do a good job at timestamping the interrupt consistently. The time measured here is the difference of the PPS timestamp vs 1 second on the system clock. This means we have: Jitter in the Telit JN3 GPS PPS signal Delay for PPS hardware in CycloneV to detect an edge. I think it had about a 200 MHz clock. Jitter in the system clock for τ=1 sec All the delays getting that interrupt to the CPU over AXI, interrupting the ARM, querying the INTC, etc. that I've already gone on about for some length. Software time spent in kernel code (Interrupt handler, GIC driver, PPS driver), before we get to create a timestamp. Of course this is just the jitter in this latency. The constant part we don't actually know. And this is usually about 1.5 µs, but can be up to 100 μs. The Corrected part of the histogram is what you'd get with a capture mode timer. In this case the clock was 50 MHz for that timer. This leaves the jitter from the first three sources: the GPS, the PPS capture hardware, and the system clock. And this puts us down in the 100 ns range, with a worse case of up to about 1 µs. So that's what using a timer to capture a PPS can provide. Two orders of magnitude decrease in jitter. We can also see that if one isn't using a timer, the jitter in how long an interrupt handler takes to generate a timestamp totally dominates the jitter from the GPS, system clock, and a timer module. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
time-n...@welwarsky.de said: > However, those quantization errors are in a range of 10s of nanoseconds, > maybe 100ns or so, ... There is another level of sawtooth/bridge that happens as the 1 ms ticks from the USB clock shift relative to the PPS. -- These are my opinions. I hate spam. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
On Sonntag, 12. Juli 2020 16:15:20 CEST Hal Murray wrote: > Don't forget hanging bridges. I don't know of any NTP software that knows > about them. If you're referring to the "sawtooth" on the 1PPS from the GPS, the NTP software shouldn't need to know. It's for whoever provides the PPS timestamps to make sure they're precise. So, if the NTP software gets its timestamps through e.g. gpsd, this entity should apply the correction. However, those quantization errors are in a range of 10s of nanoseconds, maybe 100ns or so, it depends on the internal clock of the GPS receiver to which the pulses are aligned. If your uncertainty is already in the microseconds range, correcting for a 10ns error will not be visible. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
I'll make a penultimate comment here. As is pointed out USB is good at speed, and plug-and-play - what it is not good at is deterministic time. In general the main-line Linux is also in the same boat. Put another way, one can transmit 100's of megabits of data over USB 2.0, but guaranteeing >>when<< that'll happen is a different story. USB handles that by moving giant chunks of data at a single event, rather than sending one byte at a time at a specified rate. Using what USB calls bulk transfer, a block of data is written to a FIFO, then when the host machine is ready to serve the USB driver's interrupt, it'll empty the whole buffer during that read, so that it can go service other interrupts. The actual processing of that block data may then be subject to queued handlers at an even more non-deterministic rate. In fact, I know from similar Windows experience, that it can be user space (lowest "system" priority) - where it's first come first serve. As a user, most of us are used to user-space timing. Generally at 60Hz frame-rate (1sec/60 = 16.666mSecond) if it happens within a frame or two a computer seems "responsive" or "fast". Likewise in gaming, the normal closed loop from perception to physical response is on the order of 1/8 - 1/4 second. For a 1PPS edge, that is a literal eternity. If the previously discussed Linux patch for real-time operation is used (for example "preempt-RT", which a significant effort is being made to push into the mainline kernel, see: https://www.youtube.com/watch?v=BxJm-Ujipcg ) one can get stable latencies at or under 10uSec. This is assuming some caveats: 1) The time critical task is handled by a dedicated core (i.e. setting the process "affinity" to a single core), 2) ensuring that no other time critical tasks get assigned to that core (load/unload cycles add some unpredictability to latency), and 3) the code handled during the time-critical event is not so long that it does not complete before the next event occurs. Tuning Linux to sub 10uSec latencies is possible, but at the moment it is in my opinion still a bit of "art" - so be prepared for a measure of effort to achieve the tightest control. It's important to understand that when people are talking about "real-time", they don't necessarily mean that it's fast - it means that the time understood to have elapsed is real/understood/controlled. When an event happend or is intended to have happened, is when it actually occurred (aka: low jitter, in common time nut vernacular). Another resource you might consider taking a look into is LinuxCNC - where consistent timing and low latency have a direct impact on how round a curve is, or whether a machine crashes or not. I understand that a laptop may be convenient - but I'd offer that a purpose built RaspberryPi with a dedicated high-timing accuracy GPS receiver tied to UART and a GPIO are likely to get you closer. And by hand tuning the OS implementation, considering switching from NTP to the leaner/refactored NTPSec ( https://www.ntpsec.org/ ), and perhaps looking at some of the efforts towards getting PCIe out of a RaspberryPi 4 ( https://www.hackster.io/news/pci-express-on-the-raspberry-pi-4-9b03c59f7a04 and https://hackaday.com/2020/07/01/adding-pcie-to-your-raspberry-pi-4-the-easier-way/ ) - one can add on a dedicated PCIe NIC with IEEE1588 support (something like a second-hand Mellanox ConnectX-3 Pro, p/n: MCX311A-XCCT) - because remember the RPi NIC is over USB also. It's a bit of work for certain - but it can be packaged into a project box once, and then you just throw that into a suitcase rather than having to worry about how a laptop is architected any time you have to buy a new one. Having discussed this, and watched the discussion for a few days now - I'm inspired to build one. -Tim > Date: Sat, 11 Jul 2020 18:57:39 -0700 > From: jimlux > To: time-nuts@lists.febo.com > Subject: Re: [time-nuts] Raspberry Pi NTP server > Message-ID: <8a28aabb-e419-190f-37a6-e1a147637...@earthlink.net> > Content-Type: text/plain; charset=utf-8; format=flowed > > ... > 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 (HI
Re: [time-nuts] Raspberry Pi NTP server
On 7/12/20 7:15 AM, Hal Murray wrote: stevesommars...@gmail.com said: 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? It depends on which FTDI chip you use. Both Prolific and FTDI make many chips. The common ones are slow, polling at 1 ms. The FT232R does poll at 125 microseconds. I got mine on a breakout board from AdaFruit. I also got a GPS chip on a breakout board to connect up to it. Don't forget hanging bridges. I don't know of any NTP software that knows about them. jim...@earthlink.net said: 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. I can't quite figure out what you are saying. The USB rules say that the chips commonly used for serial ports get polled at 1 ms. The FT232R says it goes faster and it works as expected at 125 microseconds. Linux may have troubles with USB code, but I'm not sure how that impacts PPS processing. The PPS timestamp is captured at interrupt time. What else matters after that? Is the PPS via USB CTS stamped at interrupt time? or is it stamped higher up in the stack? I started tracing this out, but then decided I'm not going to be writing Linux USB drivers any time soon, so gave it up. I could easily imagine that the interrupt comes in, marks a thread as "ready to run" and the "oh CTS has changed state" is detected at a higher level. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
stevesommars...@gmail.com said: > 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? It depends on which FTDI chip you use. Both Prolific and FTDI make many chips. The common ones are slow, polling at 1 ms. The FT232R does poll at 125 microseconds. I got mine on a breakout board from AdaFruit. I also got a GPS chip on a breakout board to connect up to it. Don't forget hanging bridges. I don't know of any NTP software that knows about them. jim...@earthlink.net said: > 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. I can't quite figure out what you are saying. The USB rules say that the chips commonly used for serial ports get polled at 1 ms. The FT232R says it goes faster and it works as expected at 125 microseconds. Linux may have troubles with USB code, but I'm not sure how that impacts PPS processing. The PPS timestamp is captured at interrupt time. What else matters after that? -- These are my opinions. I hate spam. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
On Sonntag, 12. Juli 2020 12:35:54 CEST Trent Piepho wrote: > That interrupt line does not go straight to the processor. It goes to > an interrupt controller, such as the ARM GIC or a proprietary > controller. The AM3358 uses a TI controller. This controller deals > with priority of interrupts, masking, level/edge triggering (this is > about how the interrupt line from the UART or GPIO controller to the > INTC acts, not about how a GPIO will trigger an interrupt), steering > of interrupts to multiple CPU cores, and finally raising the interrupt > line in a CPU core. Which might not happen immediately if another > interrupt is already executing. The interrupt controller has its own > clock domain too, running at maybe 1/2 the processor's frequency. It > takes a non-zero and non-constant amount of time for the INTC to pass > on the interrupt. If you think about using an AM3358, there's zero reason to use a GPIO for PPS input. There are much better options, like the gptimer inputs or the eCAP engine, which runs on a 200MHz clock and is therefore able to create much more accurate timestamps. GPIO is especially unsuited for fast response, since they typically have multiple sources of jitter and latency. One reason is that there's only one interrupt line per GPIO bank, each bank grouping 32 individual i/o lines. That means a lot of code to run to figure out the actual GPIO, plus dealing with level vs. edge triggering on the OS level etc. You definitely want a timestamping mechanism that is hardware supported. BR, Matthias ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
On Sat, Jul 11, 2020 at 7:37 PM jimlux wrote: > > 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. The real time kernel primarily is about trying to get closer to making hard real time guarantees. To put a hard maximum on latencies. You can't really do that on Linux, but the real time patches made it better. Mostly this is about finding a place where X could not happen in time because the CPU was doing Y instead, and Y couldn't be interrupted. And find a way to interrupt Y so X doesn't have to wait. One of the biggest changes was to thread all interrupts. So that interrupts can be interrupted. If you are after low interrupt latency, this actually makes things worse. But it makes the worst case much better than before, at the expense of the average case. > > 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 I thought Linux had USB support quite early. I remember making a cable so I could test the USB 1.0 in my 430HX based computer, the first Intel chipset to have USB. I believe it didn't work properly, some kind of chipset problem. Unless it was the 430FX, it's been so long. Google tells me the 430FX didn't have USB. But I recall that Intel's first chipset with USB had a broken controller and the Ministry of Truth changed the advertising to "it never had USB." A check shows there was Linux USB support in 1996, while Windows didn't get it until 1997. There was a big redesign of the Linux USB stack by Linus in 1999. I remember things working quite a bit better after that was done. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
On Fri, Jul 10, 2020 at 12:17 PM Tim S wrote: > > I believe the issue is arising from the understanding of "what" is being > interrupted. > > When a UART or GPIO is triggering an interrupt - for the UART it's a FIFO > notice that data is available to be pulled out, for the GPIO it's > notification of a state change (and optionally, a specific state change: > high-low/low-high). On a processor like the Ti Sitara AM3358 found in the beaglebone or the Broadcom processors in the various RPis, it's a little more complex than that. Both at the hardware level and at the software level. The UART IP block in the SoC has a module clock supplied from the processor clock tree. Likely two, one to drive the logic in the UART and another to clock the external signals. For the AM3358, there is a 100 MHz clock for the UART and an up to 48 MHz clock for the external signals. If the UART FIFO has reached a trigger point or the RTS line has changed state, the UART will only raise its interrupt line on the edge of the module clock, e.g. 100 MHz. A GPIO controller would be the same way. That interrupt line does not go straight to the processor. It goes to an interrupt controller, such as the ARM GIC or a proprietary controller. The AM3358 uses a TI controller. This controller deals with priority of interrupts, masking, level/edge triggering (this is about how the interrupt line from the UART or GPIO controller to the INTC acts, not about how a GPIO will trigger an interrupt), steering of interrupts to multiple CPU cores, and finally raising the interrupt line in a CPU core. Which might not happen immediately if another interrupt is already executing. The interrupt controller has its own clock domain too, running at maybe 1/2 the processor's frequency. It takes a non-zero and non-constant amount of time for the INTC to pass on the interrupt. Once that happens, the CPU automatically does some stuff to respond to the interrupt line. It needs to finish executing the current CPU instruction. They don't all take one cycle, so this might be more or less time. The CPU also needs to jump to the main interrupt handler, saving the current address. We haven't even run one single software instruction yet, but we are finally at the interrupt handler and have some control. But it has some stuff it must do first. Save registers, switch stacks, etc. That might access memory, which might not be cached, and so there's more delay here. It's got to figure out what interrupt occurred from the INTC. This is just a read from the memory mapped register. But that means an AXI bus transaction. The CPU sends a request over the SoC interconnect addressed to the interrupt controller. The controller sends a response back with the data. Maybe there is contention on the AXI bus due to data from other AXI masters, e.g. bus mastering DMA from the USB controller. More non-constant delays. At this point the kernel interrupt handler will have figured out the interrupt is from the UART and will call the handler registered by the UART driver, GPIO driver or maybe a PPS driver. What I've seen discussed seems to treat this as the starting point of an interrupt. But it's hardly the start. We've gone through several IP blocks, crossed a half dozen clock domains, sent and received messages via an on chip network, and executed hundreds of instructions. > When a USB PHY trips an interrupt it's to indicate that carrier data is > ready, or for a USB MAC that burst blocks over the link are being decoded. > There is an intermediate step between the USB carrier data being > received/decoded, and being interpreted by the driver as a specific type of > data - and the time that it is made available to the host OS. Because that > is handled in the driver, it is subject to all of the other host OS > interrupts - so timing is not deterministic for the USB driver. To figure out there was an interrupt from the UART, that it was due to RTS changing, and do something about it, it takes quite a few instructions. And a number of register accesses that needs to do to the UART, usually that means from over AXI to a AXI to APB interface than then APB to a UART (I've never seen a UART as an AXI master, they are always on a simpler peripheral bus like APB or OCP). This takes time. Figuring out a USB interrupt was due to the completion of an interrupt transfer, and that an interrupt is present in the end point, also takes that same stuff. Except the USB controller might be on AXI directly. It's quite a bit more complex. But there isn't really a fundamental difference on the software level. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
From: Steven Sommars [] 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. Thanks for posting your measurements, Steven. If you can find a laptop with a direct Ethernet LAN connection you may find that's quite good if (and it's a big if) you have a stratum-1 Ethernet source available. Cheers, David -- SatSignal Software - Quality software for you Web: https://www.satsignal.eu Email: david-tay...@blueyonder.co.uk Twitter: @gm8arv ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
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. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
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. On Fri, Jul 10, 2020 at 2:17 PM Tim S wrote: > I believe the issue is arising from the understanding of "what" is being > interrupted. > > When a UART or GPIO is triggering an interrupt - for the UART it's a FIFO > notice that data is available to be pulled out, for the GPIO it's > notification of a state change (and optionally, a specific state change: > high-low/low-high). > > When a USB PHY trips an interrupt it's to indicate that carrier data is > ready, or for a USB MAC that burst blocks over the link are being decoded. > There is an intermediate step between the USB carrier data being > received/decoded, and being interpreted by the driver as a specific type of > data - and the time that it is made available to the host OS. Because that > is handled in the driver, it is subject to all of the other host OS > interrupts - so timing is not deterministic for the USB driver. > > The differences here are key. > > A 1PPS wired to a GPIO interrupt for the specific pulse edge (rising) will > be associated with a very precise correlation to an interrupt vs system > tick value. > > A UART time edge (watching the seconds value increment) will be subject to > the rate at which bytes are transferred out of the UART FIFO, then math is > done to detect the second transition edge. > > A USB-to-Serial converter will first encode the bytes and status pin states > into a payload compliant with USB trafic standards, transmit that data to a > USB Host (PHY/MAC) device, which triggers and interrupt for the driver > to decode the data back into meaningful data for the host, then forwards > virtual interrupt triggers to the tasks which are watching the states and > bytes. Everything on the host-side is subject to system overhead, USB > driver optimization, etc. and is thus variable. The host-side backend of > the USB transfer is where your variability is coming from IMHO. > > This is why the recommendation is to use direct (not bridged/adapted) > UART+GPIO from most RPi NTP server projects. The timing is most critical > to the 1PPS edge, so the most direct correlation possible to a tick value > in the OS is the goal. There is nothing saying that the NMEA messages must > have such low latency however - in general they merely must arrive in time > before the next 1PPS, so USB serial is fine for that traffic. > > -Tim > > On Thu, Jul 9, 2020 at 9:00 AM wrote: > > > Message: 4 > > Date: Wed, 8 Jul 2020 15:02:49 -0500 > > From: Steven Sommars > > To: Discussion of precise time and frequency measurement > > > > Subject: Re: [time-nuts] Raspberry Pi NTP server > > Message-ID: > > > atz...@mail.gmail.com> > > Content-Type: text/plain; charset="UTF-8" > > > > My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific > > PL2303, which supports USB 2.0 > > The PPS jitter is 1 msec (e.g., using ppstest). lsusb -v shows: > > > > Bus 001 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial > > Port > > bInterval 1 > > > > which means 1 msec polling of the PPS signal. I've been unable to poll > &g
Re: [time-nuts] Raspberry Pi NTP server
I believe the issue is arising from the understanding of "what" is being interrupted. When a UART or GPIO is triggering an interrupt - for the UART it's a FIFO notice that data is available to be pulled out, for the GPIO it's notification of a state change (and optionally, a specific state change: high-low/low-high). When a USB PHY trips an interrupt it's to indicate that carrier data is ready, or for a USB MAC that burst blocks over the link are being decoded. There is an intermediate step between the USB carrier data being received/decoded, and being interpreted by the driver as a specific type of data - and the time that it is made available to the host OS. Because that is handled in the driver, it is subject to all of the other host OS interrupts - so timing is not deterministic for the USB driver. The differences here are key. A 1PPS wired to a GPIO interrupt for the specific pulse edge (rising) will be associated with a very precise correlation to an interrupt vs system tick value. A UART time edge (watching the seconds value increment) will be subject to the rate at which bytes are transferred out of the UART FIFO, then math is done to detect the second transition edge. A USB-to-Serial converter will first encode the bytes and status pin states into a payload compliant with USB trafic standards, transmit that data to a USB Host (PHY/MAC) device, which triggers and interrupt for the driver to decode the data back into meaningful data for the host, then forwards virtual interrupt triggers to the tasks which are watching the states and bytes. Everything on the host-side is subject to system overhead, USB driver optimization, etc. and is thus variable. The host-side backend of the USB transfer is where your variability is coming from IMHO. This is why the recommendation is to use direct (not bridged/adapted) UART+GPIO from most RPi NTP server projects. The timing is most critical to the 1PPS edge, so the most direct correlation possible to a tick value in the OS is the goal. There is nothing saying that the NMEA messages must have such low latency however - in general they merely must arrive in time before the next 1PPS, so USB serial is fine for that traffic. -Tim On Thu, Jul 9, 2020 at 9:00 AM wrote: > Message: 4 > Date: Wed, 8 Jul 2020 15:02:49 -0500 > From: Steven Sommars > To: Discussion of precise time and frequency measurement > > Subject: Re: [time-nuts] Raspberry Pi NTP server > Message-ID: > atz...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific > PL2303, which supports USB 2.0 > The PPS jitter is 1 msec (e.g., using ppstest). lsusb -v shows: > > Bus 001 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial > Port > bInterval 1 > > which means 1 msec polling of the PPS signal. I've been unable to poll > more frequently, that seems to require driver changes. > Petr, what polling rate do you see?Has anyone been able to poll USB @ > 125 ?sec on a stock RPi? > > With the 1 ms polling the PPS reaches the OS between 0 and 1 ms late, in an > unpredictable pattern.Although the PPS jitter is 1 msec, ntpd/chrony on > my RPi4 typically reports low dispersion: 50-150 ?sec. The zero-mean > assumption Achim mentioned is unlikely to be valid. Running chrony + > GPS+PPS/USB I see a ~640?sec offset compared to a GPS+PPS directly > connected to the GPIO pins. That offset will fluctuate, of course. > > Steve Sommars > > > ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
Driving the NTP software from a GPS w/PPS requires 1) bringing the NMEA (typically) bytes to the computer. Timing is not critical, USB polling at 1 msec is fine. 2) bringing the PPS signal into the computer *is *timing critical. There's only one bit of information. If the PPS is brought to a RPi GPIO pin, then PPS timing involves interrupt latency/jitter. This is in the microsecond range on an RPi, I'm told. If the PPS is connected to RS232 DCD pin (this is common) and connected to a computer with a native RS232 connection, we're again dealing with interrupt latency/jitter. See David Taylor's GPS wiring diagram https://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm If the PPS is connected to RS232 DCD pin, and then that RS232 signal is fed to the computer (e.g., RPi) via RS232-USB conversion, the PPS accuracy is dominated by the USB polling time. Note: The typical GPS PPS signal level isn't a direct match for RS232. In practice it works well. On Thu, Jul 9, 2020 at 1:33 PM jimlux wrote: > On 7/9/20 2:14 AM, Petr Titěra wrote: > > Just one note. Most USB to serial chip claim USB2.0 support but they > > only provide Full-Speed data transfers. That is data communication > > protocol based on USB1.1 parameters with 1ms polling interval. You have > > to specifically look for High-Speed (i.e 480mbps) transfers when going > > trough chip specification. Not all manufacturers have such chips and no > > all chips from manufacturers who provide them have such capability. > > > > To this day I was able to find only one such chip family and that is > > FTDI FT232H (that H suffix specifies High-Transfer rate). > > > > Petr Titera > > > I suspect the 1ms is not limited by the chip (after all, they all have > to support 8kHz schedules for isochronous audio, even if the serial port > doesn't use it). > > I suspect it's more an artifact of how Linux (or whatever) OS deals with > the interrupt handling. Linux isn't designed as a "real time fast > response" operating system. It depends on devices doing big transfers, > so a 1 ms response time is fine. > > That is, you set up a DMA transfer to a disk drive at 100 Mbps, but > since you're transferring 100 kByte buffers, you only need to service > the event 125 times/second. > > You'll easily see this on high speed serial links through USB if you do > "character at a time" operations. You cannot get 50kbps with character > at a time with buffer flushes between characters. > > Try it with a USB serial dongle and a loopback from TxD to RxD. > > > Most serial software that runs at high speed (>9600 bps) assumes a > slightly smarter device (maybe a 16550 style) with a FIFO, so it > "bursts" bytes to/from the device. Rather than hang a "read one > character" io call, they'll do a "read up to N characters, with a > timeout of 10 milliseconds" and put that in the loop instead. > Similarly, they'll accumulate characters to be sent, and do the io_write > call with all the characters in the buffer. > > I've done a fair amount of high speed USB serial stuff between arduinos > and PCs, and you always wind up with some scheme for buffering on both > sides. > > > Since you're not going to be transferring (batches of) bytes any more > frequently than 1 millisecond, there's not much point in sending the > "modem control" signals (RTS/CTS) through faster. Any high speed > protocol handler has to account for the fact that if RTS/CTS handshaking > is implemented, you can't overrun the transmit FIFO - That is, if the > far end drops CTS, the near end doesn't send, and bytes pile up in the > FIFO. So you just need to tell the device driver to stop sending soon > enough that the FIFO doesn't overflow. If the FIFO is, e.g., 16 deep, > and you're sending at 56 kbps (7 kBytes/sec), the FIFO will overflow in > about 2 milliseconds. So a 1 millisecond response time to the CTS > changing state is fine. > > For the other modem control signals (RI, CD, DSR, DTR) they're even > slower. DSR and DTR are basically "my power is on" and don't change > state. RI is "seconds" - the signal the modem is detecting is a 20Hz > audio tone. CD is likewise "many milliseconds" depending on the > modulation being used. A Bell 103 or 202 is a hundreds of bits/second > device, so carrier acquisition/detect is typically 10s of bit times. For > fancier modems with multitone signalling and coding, it could be many > seconds for the speed negotiation to complete. > > TL;DR - there's no reason for a USB-Serial adapter manufacturer to have > a faster than 1ms response time, nor for an operating system to be > faster than 1ms. > > > > > > > > On 08.07.2020 22:02, Steven Sommars wrote: > >> My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific > >> PL2303, which supports USB 2.0 > >> The PPS jitter is 1 msec (e.g., using ppstest). lsusb -v shows: > >> > >> Bus 001 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial > >> Port > >> bInterval 1 > >> > >> which
Re: [time-nuts] Raspberry Pi NTP server
On 7/9/20 2:14 AM, Petr Titěra wrote: Just one note. Most USB to serial chip claim USB2.0 support but they only provide Full-Speed data transfers. That is data communication protocol based on USB1.1 parameters with 1ms polling interval. You have to specifically look for High-Speed (i.e 480mbps) transfers when going trough chip specification. Not all manufacturers have such chips and no all chips from manufacturers who provide them have such capability. To this day I was able to find only one such chip family and that is FTDI FT232H (that H suffix specifies High-Transfer rate). Petr Titera I suspect the 1ms is not limited by the chip (after all, they all have to support 8kHz schedules for isochronous audio, even if the serial port doesn't use it). I suspect it's more an artifact of how Linux (or whatever) OS deals with the interrupt handling. Linux isn't designed as a "real time fast response" operating system. It depends on devices doing big transfers, so a 1 ms response time is fine. That is, you set up a DMA transfer to a disk drive at 100 Mbps, but since you're transferring 100 kByte buffers, you only need to service the event 125 times/second. You'll easily see this on high speed serial links through USB if you do "character at a time" operations. You cannot get 50kbps with character at a time with buffer flushes between characters. Try it with a USB serial dongle and a loopback from TxD to RxD. Most serial software that runs at high speed (>9600 bps) assumes a slightly smarter device (maybe a 16550 style) with a FIFO, so it "bursts" bytes to/from the device. Rather than hang a "read one character" io call, they'll do a "read up to N characters, with a timeout of 10 milliseconds" and put that in the loop instead. Similarly, they'll accumulate characters to be sent, and do the io_write call with all the characters in the buffer. I've done a fair amount of high speed USB serial stuff between arduinos and PCs, and you always wind up with some scheme for buffering on both sides. Since you're not going to be transferring (batches of) bytes any more frequently than 1 millisecond, there's not much point in sending the "modem control" signals (RTS/CTS) through faster. Any high speed protocol handler has to account for the fact that if RTS/CTS handshaking is implemented, you can't overrun the transmit FIFO - That is, if the far end drops CTS, the near end doesn't send, and bytes pile up in the FIFO. So you just need to tell the device driver to stop sending soon enough that the FIFO doesn't overflow. If the FIFO is, e.g., 16 deep, and you're sending at 56 kbps (7 kBytes/sec), the FIFO will overflow in about 2 milliseconds. So a 1 millisecond response time to the CTS changing state is fine. For the other modem control signals (RI, CD, DSR, DTR) they're even slower. DSR and DTR are basically "my power is on" and don't change state. RI is "seconds" - the signal the modem is detecting is a 20Hz audio tone. CD is likewise "many milliseconds" depending on the modulation being used. A Bell 103 or 202 is a hundreds of bits/second device, so carrier acquisition/detect is typically 10s of bit times. For fancier modems with multitone signalling and coding, it could be many seconds for the speed negotiation to complete. TL;DR - there's no reason for a USB-Serial adapter manufacturer to have a faster than 1ms response time, nor for an operating system to be faster than 1ms. On 08.07.2020 22:02, Steven Sommars wrote: My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific PL2303, which supports USB 2.0 The PPS jitter is 1 msec (e.g., using ppstest). lsusb -v shows: Bus 001 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port bInterval 1 which means 1 msec polling of the PPS signal. I've been unable to poll more frequently, that seems to require driver changes. Petr, what polling rate do you see? Has anyone been able to poll USB @ 125 µsec on a stock RPi? With the 1 ms polling the PPS reaches the OS between 0 and 1 ms late, in an unpredictable pattern. Although the PPS jitter is 1 msec, ntpd/chrony on my RPi4 typically reports low dispersion: 50-150 µsec. The zero-mean assumption Achim mentioned is unlikely to be valid. Running chrony + GPS+PPS/USB I see a ~640µsec offset compared to a GPS+PPS directly connected to the GPIO pins. That offset will fluctuate, of course. Steve Sommars On Wed, Jul 8, 2020 at 12:57 PM ASSI wrote: On Dienstag, 7. Juli 2020 18:27:01 CEST Petr Titěra wrote: Timing on USB need not to be so horrible. Below is stats from my server with GPS connected using FT232H chip (supporting high speed transfers on USB). Yes, the jitter is far greater than on other computer where PPS is connected directly but it is a lot less than that 500microseconds you get with common USB convertors. remote refid st t when poll reach delay
Re: [time-nuts] Raspberry Pi NTP server
Just one note. Most USB to serial chip claim USB2.0 support but they only provide Full-Speed data transfers. That is data communication protocol based on USB1.1 parameters with 1ms polling interval. You have to specifically look for High-Speed (i.e 480mbps) transfers when going trough chip specification. Not all manufacturers have such chips and no all chips from manufacturers who provide them have such capability. To this day I was able to find only one such chip family and that is FTDI FT232H (that H suffix specifies High-Transfer rate). Petr Titera On 08.07.2020 22:02, Steven Sommars wrote: My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific PL2303, which supports USB 2.0 The PPS jitter is 1 msec (e.g., using ppstest). lsusb -v shows: Bus 001 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port bInterval 1 which means 1 msec polling of the PPS signal. I've been unable to poll more frequently, that seems to require driver changes. Petr, what polling rate do you see?Has anyone been able to poll USB @ 125 µsec on a stock RPi? With the 1 ms polling the PPS reaches the OS between 0 and 1 ms late, in an unpredictable pattern.Although the PPS jitter is 1 msec, ntpd/chrony on my RPi4 typically reports low dispersion: 50-150 µsec. The zero-mean assumption Achim mentioned is unlikely to be valid. Running chrony + GPS+PPS/USB I see a ~640µsec offset compared to a GPS+PPS directly connected to the GPIO pins. That offset will fluctuate, of course. Steve Sommars On Wed, Jul 8, 2020 at 12:57 PM ASSI wrote: On Dienstag, 7. Juli 2020 18:27:01 CEST Petr Titěra wrote: Timing on USB need not to be so horrible. Below is stats from my server with GPS connected using FT232H chip (supporting high speed transfers on USB). Yes, the jitter is far greater than on other computer where PPS is connected directly but it is a lot less than that 500microseconds you get with common USB convertors. remote refid st t when poll reach delay offset jitter === o127.127.22.0 .PPS. 0 u7 16 377 0.000 -0.019 0.033 *192.168.3.240 .GPSD. 1 u 24 64 377 0.377 0.187 0.026 +192.168.3.246 .PPS. 1 u 28 64 377 0.643 0.181 0.028 The reason you're seeing this with the newer FTDI chips that support USB2.0 highspeed rates is that the frame rate got increased 8x for highspeed USB, so the expected frame jitter is now 125µs when and if the interface as well as the full protocol stack support and enable it. But you seem to have missed the point that Hal was trying to make: The jitter you are going to see has deterministic components and some of these can create bias when you try to filter with the usual assumption of a stationary zero-mean random sampling. In other words, you don't necessarily converge to the true time and where your filter tries to converge varies over time. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
USB: The raw BPS are between the device and the host controller - all of this is implemented in hardware. USB Low-Speed, Full-Speed and Hi-Speed use a single twisted pair in half-duplex operation. The half-duplex link multiplexes all implemented EPs (End Points). EP0 is for link management and HID (Human Interface Device). A serial port emulator uses EP1 and EP2 to implement the serial port RX and TX functions. Different devices can implement additional EPs like an interrupt EP which is still polled because the USB device cannot initiate a packet transfer. Streaming devices such as cameras and audio use (lossy) isochronous comms. USB SuperSpeed is basically the USB consortium's implementation of Firewire and uses 2 additional twisted pairs in full-duplex operation. SuperSpeed USB-3 cables are required or your device will fall back to a lower speed. The version of the USB standard does not equate to the actual speed in operation. E.g. a HID (Human Interface Device) like a mouse typically runs at 1.5MBps and can claim USB 3.1 standard compliance. Also, if link negotiation at a high speed fails then many devices are capable of a fallback to a lower speed. There are heaps of USB 2.0 devices which only support 12MBps (I wrote the firmware for one). Actual speeds can be read out from the USB root hubs and downstream hubs. The best USB net throughput you can expect for Full-Speed and Hi-Speed is about 80% of the HW bit rate. Linux interrupts: Hardware interrupts can really only be handled inside a kernel driver because the switch to user-space has too many overheads and is highly subject to scheduling constraints dictated by the system load factor. I have not configured any recent Linux kernel, but enabling the RT (Real Time) flags speeds up the interrupt latency but may actually delay the full interrupt handling because it imposes scheduling overheads - YMMV. PPS signal: If available the NTP kernel driver should be configured to use it as a hardware interrupt - this will give you the lowest possible latency and jitter. And in this case there is no need to worry about polling a serial port. On Thu, Jul 9, 2020 at 4:44 PM Steven Sommars wrote: > > I don't want to hijack Andrew's thread. Just wanted to add to Achim's > comments about jitter and offset. > > USB2 devices should accept polls every 125 microseconds. [My USB knowledge > is limited.] > > I have two devices. One is the Navisys GR701 which I suspect you're > familiar with; it is an integrated GPS + Serial->USB. The other is a > Garmin LVC18x connected to a Sabrent USB 2 to serial cable. > Both devices report having a PL2303. Both poll at 1 msec. The GR701 has a > thin cable. The Sabrent USB->Serial has a thick cable. > > > > > > > > On Wed, Jul 8, 2020 at 6:53 PM Hal Murray wrote: > > > > > stevesommars...@gmail.com said: > > > My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific > > > PL2303, which supports USB 2.0 > > > > > which means 1 msec polling of the PPS signal. I've been unable to poll > > more > > > frequently > > > > As far as I know, the PL2303, 067b:2303, is an old/slow chip. (I forget > > the > > right magic USB terms) Why do you expect it to go faster than 1 ms? > > > > It and the FTDI chip(s) are popular and widely known to be well supported > > on > > Linux. I'll be very surprised if it goes faster. > > > > What sort of device are you using? One way to tell if it is likely to go > > faster than 1 ms is the thickness of the wire. Faster speeds need more > > shielding for EMI reduction (or something like that) which turns into > > fatter > > cables. It's pretty easy to tell if you have samples of both in front of > > you. > > I think you can only use the thinner cable if t runs at 1 ms and you hard > > wire the chip to the end of the cable as is typical of a GPS mouse. > > > > > > > > -- > > These are my opinions. I hate spam. > > > > > > > > > > ___ > > 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. -- -- Manfred VK3AES ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
I don't want to hijack Andrew's thread. Just wanted to add to Achim's comments about jitter and offset. USB2 devices should accept polls every 125 microseconds. [My USB knowledge is limited.] I have two devices. One is the Navisys GR701 which I suspect you're familiar with; it is an integrated GPS + Serial->USB. The other is a Garmin LVC18x connected to a Sabrent USB 2 to serial cable. Both devices report having a PL2303. Both poll at 1 msec. The GR701 has a thin cable. The Sabrent USB->Serial has a thick cable. On Wed, Jul 8, 2020 at 6:53 PM Hal Murray wrote: > > stevesommars...@gmail.com said: > > My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific > > PL2303, which supports USB 2.0 > > > which means 1 msec polling of the PPS signal. I've been unable to poll > more > > frequently > > As far as I know, the PL2303, 067b:2303, is an old/slow chip. (I forget > the > right magic USB terms) Why do you expect it to go faster than 1 ms? > > It and the FTDI chip(s) are popular and widely known to be well supported > on > Linux. I'll be very surprised if it goes faster. > > What sort of device are you using? One way to tell if it is likely to go > faster than 1 ms is the thickness of the wire. Faster speeds need more > shielding for EMI reduction (or something like that) which turns into > fatter > cables. It's pretty easy to tell if you have samples of both in front of > you. > I think you can only use the thinner cable if t runs at 1 ms and you hard > wire the chip to the end of the cable as is typical of a GPS mouse. > > > > -- > These are my opinions. I hate spam. > > > > > ___ > 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.
Re: [time-nuts] Raspberry Pi NTP server
USB 1.0/Low-Speed: 1.5 Mbps USB 1.1/Full-Speed: 12 Mbps. USB 2.0/Hi-Speed: 480 Mbps. USB 3.0/SuperSpeed: 5 Gbps. USB 3.1/SuperSpeed: 10 Gbps. This is the actual bitrate for these serial interfaces. Bill On Wed, Jul 8, 2020, 5:16 PM jimlux wrote: > On 7/8/20 4:40 PM, Hal Murray wrote: > > > > stevesommars...@gmail.com said: > >> My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific > >> PL2303, which supports USB 2.0 > > > >> which means 1 msec polling of the PPS signal. I've been unable to > poll more > >> frequently > > > > As far as I know, the PL2303, 067b:2303, is an old/slow chip. (I forget > the > > right magic USB terms) Why do you expect it to go faster than 1 ms? > > > The underlying frame rate on USB (even the slowest USB1.0) is 8kHz, so > it's not unreasonable to expect that a chip might be able to "poll" a > status signal at that rate. > > > > > > It and the FTDI chip(s) are popular and widely known to be well > supported on > > Linux. I'll be very surprised if it goes faster. > > There is that. OTOH, drivers do get updated. One could probably, if you > were hard core, look at the device driver code in the Linux distro and > figure it out. > > > > > > What sort of device are you using? One way to tell if it is likely to go > > faster than 1 ms is the thickness of the wire. Faster speeds need more > > shielding for EMI reduction (or something like that) which turns into > fatter > > cables. It's pretty easy to tell if you have samples of both in front > of you. > > I think you can only use the thinner cable if t runs at 1 ms and you > hard > > wire the chip to the end of the cable as is typical of a GPS mouse. > > > > > > > > > ___ > 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.
Re: [time-nuts] Raspberry Pi NTP server
On 7/8/20 4:40 PM, Hal Murray wrote: stevesommars...@gmail.com said: My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific PL2303, which supports USB 2.0 which means 1 msec polling of the PPS signal. I've been unable to poll more frequently As far as I know, the PL2303, 067b:2303, is an old/slow chip. (I forget the right magic USB terms) Why do you expect it to go faster than 1 ms? It and the FTDI chip(s) are popular and widely known to be well supported on Linux. I'll be very surprised if it goes faster. it will support pretty high baud rates, though: 1,228,800 bps https://github.com/torvalds/linux/blob/master/drivers/usb/serial/pl2303.c I suspect it might have something to do with how interrupts are handled in Linux. Typically when an interrupt comes in, the interrupt handler sets a flag in the driver saying "interrupt came in", perhaps latching some status, and then returns from the interrupt immediately (so that the time spent in interrupt state is small). Then, at the next scheduling interval, a thread that is blocked waiting for the interrupt becomes alive, and actually does the rest of the processing. What sort of device are you using? One way to tell if it is likely to go faster than 1 ms is the thickness of the wire. Faster speeds need more shielding for EMI reduction (or something like that) which turns into fatter cables. It's pretty easy to tell if you have samples of both in front of you. I think you can only use the thinner cable if t runs at 1 ms and you hard wire the chip to the end of the cable as is typical of a GPS mouse. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
On 7/8/20 4:40 PM, Hal Murray wrote: stevesommars...@gmail.com said: My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific PL2303, which supports USB 2.0 which means 1 msec polling of the PPS signal. I've been unable to poll more frequently As far as I know, the PL2303, 067b:2303, is an old/slow chip. (I forget the right magic USB terms) Why do you expect it to go faster than 1 ms? The underlying frame rate on USB (even the slowest USB1.0) is 8kHz, so it's not unreasonable to expect that a chip might be able to "poll" a status signal at that rate. It and the FTDI chip(s) are popular and widely known to be well supported on Linux. I'll be very surprised if it goes faster. There is that. OTOH, drivers do get updated. One could probably, if you were hard core, look at the device driver code in the Linux distro and figure it out. What sort of device are you using? One way to tell if it is likely to go faster than 1 ms is the thickness of the wire. Faster speeds need more shielding for EMI reduction (or something like that) which turns into fatter cables. It's pretty easy to tell if you have samples of both in front of you. I think you can only use the thinner cable if t runs at 1 ms and you hard wire the chip to the end of the cable as is typical of a GPS mouse. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
stevesommars...@gmail.com said: > My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific > PL2303, which supports USB 2.0 > which means 1 msec polling of the PPS signal. I've been unable to poll more > frequently As far as I know, the PL2303, 067b:2303, is an old/slow chip. (I forget the right magic USB terms) Why do you expect it to go faster than 1 ms? It and the FTDI chip(s) are popular and widely known to be well supported on Linux. I'll be very surprised if it goes faster. What sort of device are you using? One way to tell if it is likely to go faster than 1 ms is the thickness of the wire. Faster speeds need more shielding for EMI reduction (or something like that) which turns into fatter cables. It's pretty easy to tell if you have samples of both in front of you. I think you can only use the thinner cable if t runs at 1 ms and you hard wire the chip to the end of the cable as is typical of a GPS mouse. -- These are my opinions. I hate spam. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific PL2303, which supports USB 2.0 The PPS jitter is 1 msec (e.g., using ppstest). lsusb -v shows: Bus 001 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port bInterval 1 which means 1 msec polling of the PPS signal. I've been unable to poll more frequently, that seems to require driver changes. Petr, what polling rate do you see?Has anyone been able to poll USB @ 125 µsec on a stock RPi? With the 1 ms polling the PPS reaches the OS between 0 and 1 ms late, in an unpredictable pattern.Although the PPS jitter is 1 msec, ntpd/chrony on my RPi4 typically reports low dispersion: 50-150 µsec. The zero-mean assumption Achim mentioned is unlikely to be valid. Running chrony + GPS+PPS/USB I see a ~640µsec offset compared to a GPS+PPS directly connected to the GPIO pins. That offset will fluctuate, of course. Steve Sommars On Wed, Jul 8, 2020 at 12:57 PM ASSI wrote: > On Dienstag, 7. Juli 2020 18:27:01 CEST Petr Titěra wrote: > > Timing on USB need not to be so horrible. Below is stats from my server > > with GPS connected using FT232H chip (supporting high speed transfers on > > USB). Yes, the jitter is far greater than on other computer where PPS is > > connected directly but it is a lot less than that 500microseconds you > > get with common USB convertors. > > > > remote refid st t when poll reach delay offset jitter > > === > > o127.127.22.0 .PPS. 0 u7 16 377 0.000 -0.019 0.033 > > *192.168.3.240 .GPSD. 1 u 24 64 377 0.377 0.187 0.026 > > +192.168.3.246 .PPS. 1 u 28 64 377 0.643 0.181 0.028 > > The reason you're seeing this with the newer FTDI chips that support > USB2.0 > highspeed rates is that the frame rate got increased 8x for highspeed USB, > so > the expected frame jitter is now 125µs when and if the interface as well > as > the full protocol stack support and enable it. But you seem to have > missed > the point that Hal was trying to make: The jitter you are going to see has > deterministic components and some of these can create bias when you try to > filter with the usual assumption of a stationary zero-mean random > sampling. > In other words, you don't necessarily converge to the true time and where > your > filter tries to converge varies over time. > > > Regards, > Achim. > -- > +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ > > DIY Stuff: > http://Synth.Stromeko.net/DIY.html > > > > > ___ > 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.
Re: [time-nuts] Raspberry Pi NTP server
On Dienstag, 7. Juli 2020 18:27:01 CEST Petr Titěra wrote: > Timing on USB need not to be so horrible. Below is stats from my server > with GPS connected using FT232H chip (supporting high speed transfers on > USB). Yes, the jitter is far greater than on other computer where PPS is > connected directly but it is a lot less than that 500microseconds you > get with common USB convertors. > > remote refid st t when poll reach delay offset jitter > === > o127.127.22.0 .PPS. 0 u7 16 377 0.000 -0.019 0.033 > *192.168.3.240 .GPSD. 1 u 24 64 377 0.377 0.187 0.026 > +192.168.3.246 .PPS. 1 u 28 64 377 0.643 0.181 0.028 The reason you're seeing this with the newer FTDI chips that support USB2.0 highspeed rates is that the frame rate got increased 8x for highspeed USB, so the expected frame jitter is now 125µs when and if the interface as well as the full protocol stack support and enable it. But you seem to have missed the point that Hal was trying to make: The jitter you are going to see has deterministic components and some of these can create bias when you try to filter with the usual assumption of a stationary zero-mean random sampling. In other words, you don't necessarily converge to the true time and where your filter tries to converge varies over time. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
Timing on USB need not to be so horrible. Below is stats from my server with GPS connected using FT232H chip (supporting high speed transfers on USB). Yes, the jitter is far greater than on other computer where PPS is connected directly but it is a lot less than that 500microseconds you get with common USB convertors. remote refid st t when poll reach delay offset jitter === o127.127.22.0 .PPS. 0 u7 16 377 0.000 -0.019 0.033 *192.168.3.240 .GPSD. 1 u 24 64 377 0.377 0.187 0.026 +192.168.3.246 .PPS. 1 u 28 64 377 0.643 0.181 0.028 Petr Titera On 03.07.2020 19:44, Hal Murray wrote: andrew.hanc...@cyrus-consultants.co.uk said: So I cannot use HaTs anymore, so I cobbled together a GPS ublox6 (same module) but using a FT232RL, and connected all the pins correctly, and DCD so I can get PPS. FT232R is a USB chip. Timing over USB is "interesting". Do you know about hanging bridges? Can you get a wire in to the GPIO pin the HAT used? That would be an interesting experiment. There may be a parameter you can tweak, but I can't think of the name right now. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
Hi > On Jul 6, 2020, at 11:43 AM, Matthias Welwarsky > wrote: > > On Samstag, 4. Juli 2020 16:49:11 CEST David J Taylor via time-nuts wrote: > >> Matthias, my feeling is that if you want a precision source, neither BB not >> the RPi is a good solution. Maybe with all the tweak you mentioned the BB >> approaches precision (for some values of precision). I see the RPi as >> something which can provide far better NTP than simply using an Internet >> source, something which will be adequate for the majority of users (for some >> types of user!). > > If your wall clock runs locked to GPS time, which it is by definition if you > drive its counter directly from a GPSDO, then it cannot drift away from GPS > time. Sticking with the “wall clock” analogy for a bit here: The edge comes into the clock. A device of some sort recognizes the edge This drives some sort of process inside that device. That process (eventually) gets around to talking to a stepper motor driver The stepper driver ramps up and “kicks” the motor based on it’s own internal design The stepper motor magnetizes and feeds a bit of energy to the clock mechanics. There *may* be multiple kicks per second, depending on how the mechanical side was done Everything past the “edge comes in” has variability to it. There are delays and those delays probably are temperature and voltage dependent. Even in a *very* simple looking system, the net result likely isn’t anywhere near 100 ns …. Why dig into this? Pretty much every other timing device out there has the same sort of multi layer problems ….. The sources will be different, but problems none the less. Bob > ……….. > > As far as "for some types of users" is concerned - this list is called "time- > nuts" for a reason, isn't it? > > :-) > > Best regards, > Matthias > > > > ___ > 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.
Re: [time-nuts] Raspberry Pi NTP server
On Samstag, 4. Juli 2020 16:49:11 CEST David J Taylor via time-nuts wrote: > Matthias, my feeling is that if you want a precision source, neither BB not > the RPi is a good solution. Maybe with all the tweak you mentioned the BB > approaches precision (for some values of precision). I see the RPi as > something which can provide far better NTP than simply using an Internet > source, something which will be adequate for the majority of users (for some > types of user!). If your wall clock runs locked to GPS time, which it is by definition if you drive its counter directly from a GPSDO, then it cannot drift away from GPS time. If you timestamp the 1PPS pulse from the same GPSDO using the same counter in capture mode, the NTP server will have easy game once the initial time stepping is done. The system time will always be locked to GPS time, with a 100ns uncertainty given by the counter granularity when clocked with 10 MHz. This is the baseline of what can be achieved with such setup. Everything else is a question of your time distribution system. As far as "for some types of users" is concerned - this list is called "time- nuts" for a reason, isn't it? :-) Best regards, Matthias ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
Andrew, outlier rejection in NTPD is not the most stable thing in the world. You have two local refclocks that are consistently 200ms off from the "rest of the world" and this is 10 times larger than the round trip delay to the rest of the world. But the local stratum 0 refclock poll interval is ten or twenty times more frequent than the rest of the world so the local wrong clock gets to trigger the algorithm ten times as often as the rest of the world. The outlier rejection NTPD algorithm goes absolutely bonkers in this case. Which is good because you see it and fix the actual problem. Like David suggested, seeing the 200ms offset, this 200ms is a very common default PPS pulse width so it almost certainly is triggering off the wrong edge. Tim N3QE On Sun, Jul 5, 2020 at 7:50 AM Andrew Hancock < andrew.hanc...@cyrus-consultants.co.uk> wrote: > Thanks David > > I may try that list. > > It is odd, it works fine, and then craps out > > And then it's happy again... > > Andrew > > -Original Message- > From: time-nuts On Behalf Of David J > Taylor via time-nuts > Sent: 03 July 2020 18:34 > To: time-nuts@lists.febo.com > Cc: David J Taylor > Subject: Re: [time-nuts] Raspberry Pi NTP server > > A puzzle (so I hope) I'm in the correct place. > > I've built myself, many years ago an NTP server, on a RPi 1, which not > sure if ever ran properly. > > It uses a u-blox6 board, connected to the Pi correctly, and PPS to GPIO, > compiled NTP to include kernel PPS support. > > GPS 3D fix is fine, using an outside aerial, there are no issues here > reported with cgps -s or gpsmon, but recently I've racked mounted all my > PIs in a network rack. > > So I cannot use HaTs anymore, so I cobbled together a GPS ublox6 (same > module) but using a FT232RL, and connected all the pins correctly, and DCD > so I can get PPS. > > Cgps -s and gpsmon, reports all is well, pps registers correctly... > > But here's the weird thing, it starts out okay, from what I can tell, and > I get 377 for both GPSD and PPS > > remote refid st t when poll reach delay offset > jitter > > == > *127.127.28.0.GPSD. 1 l 21 32 370.000 98.447 > 89.508 > o127.127.22.0.PPS.0 l 20 32 170.000 -63.468 > 27.800 > uk.pool.ntp.org .POOL. 16 p- 102400.0000.000 > 0.004 > +212.23.8.6 195.66.241.2 2 u 129 10241 13.266 198.007 > 3.273 > +212.23.10.129 85.199.214.992 u 134 10241 19.693 195.605 > 3.282 > +178.62.18.7685.199.214.100 2 u 135 10241 13.804 195.465 > 3.299 > +185.120.34.123 85.199.214.982 u 130 10241 12.808 197.879 > 3.304 > +51.68.198.213 85.199.214.102 2 u 132 10241 13.534 197.377 > 3.402 > +95.215.175.2178.79.160.573 u 131 10241 19.722 198.984 > 3.244 > > And then later. > > remote refid st t when poll reach delay offset > jitter > > == > *127.127.28.0.GPSD. 1 l 20 32 3770.000 -38.512 > 43.162 > x127.127.22.0.PPS.0 l 19 32 3770.000 -159.01 > 0.949 > uk.pool.ntp.org .POOL. 16 p- 102400.0000.000 > 0.004 > +212.23.8.6 195.66.241.2 2 u 255 10241 13.615 142.618 > 1.953 > +212.23.10.129 85.199.214.992 u 261 10241 19.799 144.028 > 3.384 > +162.159.200.123 10.63.8.83 u 258 10241 18.501 141.995 > 3.016 > +185.53.93.157 81.187.26.1742 u 258 10241 15.385 143.600 > 3.045 > -217.114.59.333.117.170.502 u 259 10241 19.927 143.014 > 3.364 > +109.74.192.97 85.199.214.992 u 255 10241 13.578 142.723 > 1.864 > > Which does not look good, notice the x in front of PPS... > > And then sometimes It borks.. and drops out completely and * and x > disappear, and all the +. > > Then go back to > > > remote refid st t when poll reach delay offset > jitter > > == > *127.127.28.0.GPSD. 1 l 27 6430.000 34.096 > 1.954 > o127.127.22.0.PPS.0 l 26 3230.000 -69.865 > 14.194 > uk.pool.ntp.org .POOL. 16 p- 102400.0000.000 > 0.002 > 212.23.8.6 195.66.241.2 2 u 121 10241 13.316 200.644 > 0.002 > 212.23.10.129 85.199.214.992 u 118 10241 19.929 202.213 > 0.002 > 178.79.155.116 85.199.214.992 u 120 10
Re: [time-nuts] Raspberry Pi NTP server
On 03/07/2020 13:56, Andrew Hancock wrote: But here's the weird thing, it starts out okay, from what I can tell, and I get 377 for both GPSD and PPS remote refid st t when poll reach delay offset jitter == *127.127.28.0.GPSD. 1 l 21 32 370.000 98.447 89.508 o127.127.22.0.PPS.0 l 20 32 170.000 -63.468 27.800 That's NOT ok, IMHO :-) I think the offset and jitter for the PPS server are far too high. Here's what my Raspberry Pi2 looks like: $ ntpq -p remote refid st t when poll reach delay offset jitter == *SHM(0) .SHM. 0 l 7 16 377 0.000 -90.737 65.556 oPPS(0) .PPS. 0 l 5 16 377 0.000 0.002 0.002 +ntp0... (other NTP servers omitted but 0ffset values were 1 or 2 ms) My setup sounds like your original, with a GPS Hat and PPS on a GPIO line. The huge difference between your remote servers and your PPS signal suggest (as others have said) that the timing of your PPS signal is wrong. I think that is the cause of your problems. Steve ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
On 7/3/20 8:56 AM, Andrew Hancock wrote: GPS 3D fix is fine, using an outside aerial, there are no issues here reported with cgps -s or gpsmon, but recently I've racked mounted all my PIs in a network rack. Have you ruled out thermal issues with the Pi being in a rack? ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
Thanks David I may try that list. It is odd, it works fine, and then craps out And then it's happy again... Andrew -Original Message- From: time-nuts On Behalf Of David J Taylor via time-nuts Sent: 03 July 2020 18:34 To: time-nuts@lists.febo.com Cc: David J Taylor Subject: Re: [time-nuts] Raspberry Pi NTP server A puzzle (so I hope) I'm in the correct place. I've built myself, many years ago an NTP server, on a RPi 1, which not sure if ever ran properly. It uses a u-blox6 board, connected to the Pi correctly, and PPS to GPIO, compiled NTP to include kernel PPS support. GPS 3D fix is fine, using an outside aerial, there are no issues here reported with cgps -s or gpsmon, but recently I've racked mounted all my PIs in a network rack. So I cannot use HaTs anymore, so I cobbled together a GPS ublox6 (same module) but using a FT232RL, and connected all the pins correctly, and DCD so I can get PPS. Cgps -s and gpsmon, reports all is well, pps registers correctly... But here's the weird thing, it starts out okay, from what I can tell, and I get 377 for both GPSD and PPS remote refid st t when poll reach delay offset jitter == *127.127.28.0.GPSD. 1 l 21 32 370.000 98.447 89.508 o127.127.22.0.PPS.0 l 20 32 170.000 -63.468 27.800 uk.pool.ntp.org .POOL. 16 p- 102400.0000.000 0.004 +212.23.8.6 195.66.241.2 2 u 129 10241 13.266 198.007 3.273 +212.23.10.129 85.199.214.992 u 134 10241 19.693 195.605 3.282 +178.62.18.7685.199.214.100 2 u 135 10241 13.804 195.465 3.299 +185.120.34.123 85.199.214.982 u 130 10241 12.808 197.879 3.304 +51.68.198.213 85.199.214.102 2 u 132 10241 13.534 197.377 3.402 +95.215.175.2178.79.160.573 u 131 10241 19.722 198.984 3.244 And then later. remote refid st t when poll reach delay offset jitter == *127.127.28.0.GPSD. 1 l 20 32 3770.000 -38.512 43.162 x127.127.22.0.PPS.0 l 19 32 3770.000 -159.01 0.949 uk.pool.ntp.org .POOL. 16 p- 102400.0000.000 0.004 +212.23.8.6 195.66.241.2 2 u 255 10241 13.615 142.618 1.953 +212.23.10.129 85.199.214.992 u 261 10241 19.799 144.028 3.384 +162.159.200.123 10.63.8.83 u 258 10241 18.501 141.995 3.016 +185.53.93.157 81.187.26.1742 u 258 10241 15.385 143.600 3.045 -217.114.59.333.117.170.502 u 259 10241 19.927 143.014 3.364 +109.74.192.97 85.199.214.992 u 255 10241 13.578 142.723 1.864 Which does not look good, notice the x in front of PPS... And then sometimes It borks.. and drops out completely and * and x disappear, and all the +. Then go back to remote refid st t when poll reach delay offset jitter == *127.127.28.0.GPSD. 1 l 27 6430.000 34.096 1.954 o127.127.22.0.PPS.0 l 26 3230.000 -69.865 14.194 uk.pool.ntp.org .POOL. 16 p- 102400.0000.000 0.002 212.23.8.6 195.66.241.2 2 u 121 10241 13.316 200.644 0.002 212.23.10.129 85.199.214.992 u 118 10241 19.929 202.213 0.002 178.79.155.116 85.199.214.992 u 120 10241 13.391 201.057 0.002 185.121.25.242 85.199.214.992 u 121 10241 14.084 200.964 0.002 81.21.65.169195.195.221.100 2 u 122 10241 17.587 200.121 0.002 178.62.6.8 68.166.61.2552 u 122 10241 13.864 200.580 0.002 I'm beginning to wonder my testing using Meinberg polling every 10 seconds is causing the Pi an issue! remote refid st t when poll reach delay offset jitter == *127.127.28.0.GPSD. 1 l 13 64 3770.000 144.454 69.663 o127.127.22.0.PPS.0 l 12 32 3770.000 59.311 19.278 uk.pool.ntp.org .POOL. 16 p- 102400.0000.000 0.002 212.23.8.6 195.66.241.2 2 u 491 10241 13.316 200.644 0.002 212.23.10.129 85.199.214.992 u 489 10241 19.929 202.213 0.002 178.79.155.116 85.199.214.992 u 491 10241 13.391 201.057 0.002 185.121.25.242 85.199.214.992 u 492 10241 14.084 200.964 0.002 81.21.65.169195.195.221.100 2 u 493 10241 17.587 200.121 0.002 178.62.6.8 68.166.61.2552 u 493 10241 13.864 200.580 0.002 Stopped monitoring, see if it stops... Thanks for your comments == Andrew, Three thoughts: - any
Re: [time-nuts] Raspberry Pi NTP server
Thanks Hal I could try and get a wire onto the GPIO, with a lot of work... Andrew -Original Message- From: time-nuts On Behalf Of Hal Murray Sent: 03 July 2020 18:45 To: Discussion of precise time and frequency measurement Cc: hmur...@megapathdsl.net Subject: Re: [time-nuts] Raspberry Pi NTP server andrew.hanc...@cyrus-consultants.co.uk said: > So I cannot use HaTs anymore, so I cobbled together a GPS ublox6 (same > module) but using a FT232RL, and connected all the pins correctly, and > DCD so I can get PPS. FT232R is a USB chip. Timing over USB is "interesting". Do you know about hanging bridges? Can you get a wire in to the GPIO pin the HAT used? That would be an interesting experiment. There may be a parameter you can tweak, but I can't think of the name right now. -- These are my opinions. I hate spam. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
On 7/4/20 7:49 AM, David J Taylor via time-nuts wrote: David, I've seen your comparison in the list archives. However, none of the approaches I have seen published so far (including yours) exploit all the possibilities I mentioned. The Raspi having better community support doesn't help if the platform itself is unfit for the purpose. It might be OK as a general purpose NTP server if you don't have any special requirements to accuracy, but for a PTPv2 grandmaster, having the ethernet behind a USB interface is a no-go. Regarding the RF interference - I'm running a Ublox M8T module directly mounted on the BBB via my custom GPSDO cape. It is working just fine. Disabling the onboard HDMI encoder might be the "secret sauce" for success. BR, Matthias === Matthias, my feeling is that if you want a precision source, neither BB not the RPi is a good solution. Maybe with all the tweak you mentioned the BB approaches precision (for some values of precision). I see the RPi as something which can provide far better NTP than simply using an Internet source, something which will be adequate for the majority of users (for some types of user!). The RPi 4 doesn't have E/net over USB hence my comment on seeing a comparison. The RF interference is to other parts of the spectrum - not specifically 1.5 GHz GPS - and has been documented. I noticed it on either 145 or 435 MHz bands when testing. [Jim] Whether anyone has bothered to do proper measurements I doubt. I was wondering more about non-GPS band interference.. And whether anything was hooked up to it. I've got some RTL-SDRs here, and I've connected them both to an older RPi and some BBs, and with a whip antenna about a meter away, I've not noticed a huge difference between them, in a sort of casual way. They're both noisy, but then, I don't know if it's the environment, or other stuff hooked up to them (Ethernet or USB cables, or the USB power supply). I wouldn't expect them to be hugely different from an RFI standpoint as bare boards with nothing else connected. It's stuff that's connected is more likely the source, by conduction from the board then radiation from the wires. That's why I was asking about the details. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
David, I've seen your comparison in the list archives. However, none of the approaches I have seen published so far (including yours) exploit all the possibilities I mentioned. The Raspi having better community support doesn't help if the platform itself is unfit for the purpose. It might be OK as a general purpose NTP server if you don't have any special requirements to accuracy, but for a PTPv2 grandmaster, having the ethernet behind a USB interface is a no-go. Regarding the RF interference - I'm running a Ublox M8T module directly mounted on the BBB via my custom GPSDO cape. It is working just fine. Disabling the onboard HDMI encoder might be the "secret sauce" for success. BR, Matthias === Matthias, my feeling is that if you want a precision source, neither BB not the RPi is a good solution. Maybe with all the tweak you mentioned the BB approaches precision (for some values of precision). I see the RPi as something which can provide far better NTP than simply using an Internet source, something which will be adequate for the majority of users (for some types of user!). The RPi 4 doesn't have E/net over USB hence my comment on seeing a comparison. The RF interference is to other parts of the spectrum - not specifically 1.5 GHz GPS - and has been documented. I noticed it on either 145 or 435 MHz bands when testing. [Jim] Whether anyone has bothered to do proper measurements I doubt. Cheers, David -- SatSignal Software - Quality software for you Web: https://www.satsignal.eu Email: david-tay...@blueyonder.co.uk Twitter: @gm8arv ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
On 7/4/20 2:30 AM, David J Taylor via time-nuts wrote: ... and it has much less general support ... and it generates more RF interference ... and it costs money as the OP already has the Raspberry Pi I have both Pis and BB Blacks and Greens and Green wireless. I'm interested in the RF interference aspect - is that documented anywhere? Yeah, I'm sure both meet the respective Part 15 for WiFi transmitters (if they have a WiFi interface on board) - but I've not seen any substantive measurement data for general RFI. And given COVID telework, I can't just run down to the screen room with them and a spectrum analyzer. ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
On Samstag, 4. Juli 2020 11:30:01 CEST David J Taylor via time-nuts wrote: > From: Matthias Welwarsky > [] > Forgive me chiming in with a recommendation: Drop the Raspberry Pi and get a > Beaglebone Black instead. It is the much better platform for timekeeping > experiments. [snip] > BR, > Matthias > === > > ... and it has much less general support > ... and it generates more RF interference > ... and it costs money as the OP already has the Raspberry Pi > > Neither make for "precision" sources. I've yet to see a comparison between > the BeagleBone and a Raspberry Pi 4. I did make a comparison earlier which > showed the BBB to be better, yes, but certainly not enough for me to change > given the other factors. David, I've seen your comparison in the list archives. However, none of the approaches I have seen published so far (including yours) exploit all the possibilities I mentioned. The Raspi having better community support doesn't help if the platform itself is unfit for the purpose. It might be OK as a general purpose NTP server if you don't have any special requirements to accuracy, but for a PTPv2 grandmaster, having the ethernet behind a USB interface is a no-go. Regarding the RF interference - I'm running a Ublox M8T module directly mounted on the BBB via my custom GPSDO cape. It is working just fine. Disabling the onboard HDMI encoder might be the "secret sauce" for success. BR, Matthias > > Cheers, > David ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
From: Matthias Welwarsky [] Forgive me chiming in with a recommendation: Drop the Raspberry Pi and get a Beaglebone Black instead. It is the much better platform for timekeeping experiments. Firstly, it has capture-mode timers that will give much more stable timestamps for the 1PPS kernel interface. Secondly, you can drive these timers from an external clock source. That clock source can be a GPSDO. That means, you can hook up the timer input clock to the 10MHz GPSDO output and at the same time use it for timestamping the GPSDO 1PPS pulses. Plus, this timer can be the "wall clock" for the Linux system, resulting in a zero-drift system time. Combine that with gpsd and you have a stratum-1 time source. Thirdly, the ethernet mac is on chip and it supports hardware timestamps. This means, not only NTP but also PTPv2 is possible. BR, Matthias === ... and it has much less general support ... and it generates more RF interference ... and it costs money as the OP already has the Raspberry Pi Neither make for "precision" sources. I've yet to see a comparison between the BeagleBone and a Raspberry Pi 4. I did make a comparison earlier which showed the BBB to be better, yes, but certainly not enough for me to change given the other factors. Cheers, David -- SatSignal Software - Quality software for you Web: https://www.satsignal.eu Email: david-tay...@blueyonder.co.uk Twitter: @gm8arv ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
On Freitag, 3. Juli 2020 19:44:48 CEST Hal Murray wrote: > andrew.hanc...@cyrus-consultants.co.uk said: > > So I cannot use HaTs anymore, so I cobbled together a GPS ublox6 (same > > module) but using a FT232RL, and connected all the pins correctly, and DCD > > so I can get PPS. > > FT232R is a USB chip. Timing over USB is "interesting". Do you know about > hanging bridges? > > Can you get a wire in to the GPIO pin the HAT used? That would be an > interesting experiment. > > There may be a parameter you can tweak, but I can't think of the name right > now. Forgive me chiming in with a recommendation: Drop the Raspberry Pi and get a Beaglebone Black instead. It is the much better platform for timekeeping experiments. Firstly, it has capture-mode timers that will give much more stable timestamps for the 1PPS kernel interface. Secondly, you can drive these timers from an external clock source. That clock source can be a GPSDO. That means, you can hook up the timer input clock to the 10MHz GPSDO output and at the same time use it for timestamping the GPSDO 1PPS pulses. Plus, this timer can be the "wall clock" for the Linux system, resulting in a zero-drift system time. Combine that with gpsd and you have a stratum-1 time source. Thirdly, the ethernet mac is on chip and it supports hardware timestamps. This means, not only NTP but also PTPv2 is possible. BR, Matthias ___ 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.
Re: [time-nuts] Raspberry Pi NTP server
A puzzle (so I hope) I'm in the correct place. I've built myself, many years ago an NTP server, on a RPi 1, which not sure if ever ran properly. It uses a u-blox6 board, connected to the Pi correctly, and PPS to GPIO, compiled NTP to include kernel PPS support. GPS 3D fix is fine, using an outside aerial, there are no issues here reported with cgps -s or gpsmon, but recently I've racked mounted all my PIs in a network rack. So I cannot use HaTs anymore, so I cobbled together a GPS ublox6 (same module) but using a FT232RL, and connected all the pins correctly, and DCD so I can get PPS. Cgps -s and gpsmon, reports all is well, pps registers correctly... But here's the weird thing, it starts out okay, from what I can tell, and I get 377 for both GPSD and PPS remote refid st t when poll reach delay offset jitter == *127.127.28.0.GPSD. 1 l 21 32 370.000 98.447 89.508 o127.127.22.0.PPS.0 l 20 32 170.000 -63.468 27.800 uk.pool.ntp.org .POOL. 16 p- 102400.0000.000 0.004 +212.23.8.6 195.66.241.2 2 u 129 10241 13.266 198.007 3.273 +212.23.10.129 85.199.214.992 u 134 10241 19.693 195.605 3.282 +178.62.18.7685.199.214.100 2 u 135 10241 13.804 195.465 3.299 +185.120.34.123 85.199.214.982 u 130 10241 12.808 197.879 3.304 +51.68.198.213 85.199.214.102 2 u 132 10241 13.534 197.377 3.402 +95.215.175.2178.79.160.573 u 131 10241 19.722 198.984 3.244 And then later. remote refid st t when poll reach delay offset jitter == *127.127.28.0.GPSD. 1 l 20 32 3770.000 -38.512 43.162 x127.127.22.0.PPS.0 l 19 32 3770.000 -159.01 0.949 uk.pool.ntp.org .POOL. 16 p- 102400.0000.000 0.004 +212.23.8.6 195.66.241.2 2 u 255 10241 13.615 142.618 1.953 +212.23.10.129 85.199.214.992 u 261 10241 19.799 144.028 3.384 +162.159.200.123 10.63.8.83 u 258 10241 18.501 141.995 3.016 +185.53.93.157 81.187.26.1742 u 258 10241 15.385 143.600 3.045 -217.114.59.333.117.170.502 u 259 10241 19.927 143.014 3.364 +109.74.192.97 85.199.214.992 u 255 10241 13.578 142.723 1.864 Which does not look good, notice the x in front of PPS... And then sometimes It borks.. and drops out completely and * and x disappear, and all the +. Then go back to remote refid st t when poll reach delay offset jitter == *127.127.28.0.GPSD. 1 l 27 6430.000 34.096 1.954 o127.127.22.0.PPS.0 l 26 3230.000 -69.865 14.194 uk.pool.ntp.org .POOL. 16 p- 102400.0000.000 0.002 212.23.8.6 195.66.241.2 2 u 121 10241 13.316 200.644 0.002 212.23.10.129 85.199.214.992 u 118 10241 19.929 202.213 0.002 178.79.155.116 85.199.214.992 u 120 10241 13.391 201.057 0.002 185.121.25.242 85.199.214.992 u 121 10241 14.084 200.964 0.002 81.21.65.169195.195.221.100 2 u 122 10241 17.587 200.121 0.002 178.62.6.8 68.166.61.2552 u 122 10241 13.864 200.580 0.002 I'm beginning to wonder my testing using Meinberg polling every 10 seconds is causing the Pi an issue! remote refid st t when poll reach delay offset jitter == *127.127.28.0.GPSD. 1 l 13 64 3770.000 144.454 69.663 o127.127.22.0.PPS.0 l 12 32 3770.000 59.311 19.278 uk.pool.ntp.org .POOL. 16 p- 102400.0000.000 0.002 212.23.8.6 195.66.241.2 2 u 491 10241 13.316 200.644 0.002 212.23.10.129 85.199.214.992 u 489 10241 19.929 202.213 0.002 178.79.155.116 85.199.214.992 u 491 10241 13.391 201.057 0.002 185.121.25.242 85.199.214.992 u 492 10241 14.084 200.964 0.002 81.21.65.169195.195.221.100 2 u 493 10241 17.587 200.121 0.002 178.62.6.8 68.166.61.2552 u 493 10241 13.864 200.580 0.002 Stopped monitoring, see if it stops... Thanks for your comments == Andrew, Three thoughts: - any chance the DCD pulse is the wrong polarity? Triggering on the trailing an not the leading edge? Might give errors typically around 100 ms (the pulse width), but your errors seem to be more in the 250-300 ms range. - WNRO (week number roll over) issue? - unless you need stand-alone operation, try commenting out the type
Re: [time-nuts] Raspberry Pi NTP server
andrew.hanc...@cyrus-consultants.co.uk said: > So I cannot use HaTs anymore, so I cobbled together a GPS ublox6 (same > module) but using a FT232RL, and connected all the pins correctly, and DCD so > I can get PPS. FT232R is a USB chip. Timing over USB is "interesting". Do you know about hanging bridges? Can you get a wire in to the GPIO pin the HAT used? That would be an interesting experiment. There may be a parameter you can tweak, but I can't think of the name right now. -- These are my opinions. I hate spam. ___ 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] Raspberry Pi NTP server
A puzzle (so I hope) I'm in the correct place. I've built myself, many years ago an NTP server, on a RPi 1, which not sure if ever ran properly. It uses a u-blox6 board, connected to the Pi correctly, and PPS to GPIO, compiled NTP to include kernel PPS support. GPS 3D fix is fine, using an outside aerial, there are no issues here reported with cgps -s or gpsmon, but recently I've racked mounted all my PIs in a network rack. So I cannot use HaTs anymore, so I cobbled together a GPS ublox6 (same module) but using a FT232RL, and connected all the pins correctly, and DCD so I can get PPS. Cgps -s and gpsmon, reports all is well, pps registers correctly... But here's the weird thing, it starts out okay, from what I can tell, and I get 377 for both GPSD and PPS remote refid st t when poll reach delay offset jitter == *127.127.28.0.GPSD. 1 l 21 32 370.000 98.447 89.508 o127.127.22.0.PPS.0 l 20 32 170.000 -63.468 27.800 uk.pool.ntp.org .POOL. 16 p- 102400.0000.000 0.004 +212.23.8.6 195.66.241.2 2 u 129 10241 13.266 198.007 3.273 +212.23.10.129 85.199.214.992 u 134 10241 19.693 195.605 3.282 +178.62.18.7685.199.214.100 2 u 135 10241 13.804 195.465 3.299 +185.120.34.123 85.199.214.982 u 130 10241 12.808 197.879 3.304 +51.68.198.213 85.199.214.102 2 u 132 10241 13.534 197.377 3.402 +95.215.175.2178.79.160.573 u 131 10241 19.722 198.984 3.244 And then later. remote refid st t when poll reach delay offset jitter == *127.127.28.0.GPSD. 1 l 20 32 3770.000 -38.512 43.162 x127.127.22.0.PPS.0 l 19 32 3770.000 -159.01 0.949 uk.pool.ntp.org .POOL. 16 p- 102400.0000.000 0.004 +212.23.8.6 195.66.241.2 2 u 255 10241 13.615 142.618 1.953 +212.23.10.129 85.199.214.992 u 261 10241 19.799 144.028 3.384 +162.159.200.123 10.63.8.83 u 258 10241 18.501 141.995 3.016 +185.53.93.157 81.187.26.1742 u 258 10241 15.385 143.600 3.045 -217.114.59.333.117.170.502 u 259 10241 19.927 143.014 3.364 +109.74.192.97 85.199.214.992 u 255 10241 13.578 142.723 1.864 Which does not look good, notice the x in front of PPS... And then sometimes It borks.. and drops out completely and * and x disappear, and all the +. Then go back to remote refid st t when poll reach delay offset jitter == *127.127.28.0.GPSD. 1 l 27 6430.000 34.096 1.954 o127.127.22.0.PPS.0 l 26 3230.000 -69.865 14.194 uk.pool.ntp.org .POOL. 16 p- 102400.0000.000 0.002 212.23.8.6 195.66.241.2 2 u 121 10241 13.316 200.644 0.002 212.23.10.129 85.199.214.992 u 118 10241 19.929 202.213 0.002 178.79.155.116 85.199.214.992 u 120 10241 13.391 201.057 0.002 185.121.25.242 85.199.214.992 u 121 10241 14.084 200.964 0.002 81.21.65.169195.195.221.100 2 u 122 10241 17.587 200.121 0.002 178.62.6.8 68.166.61.2552 u 122 10241 13.864 200.580 0.002 I'm beginning to wonder my testing using Meinberg polling every 10 seconds is causing the Pi an issue! remote refid st t when poll reach delay offset jitter == *127.127.28.0.GPSD. 1 l 13 64 3770.000 144.454 69.663 o127.127.22.0.PPS.0 l 12 32 3770.000 59.311 19.278 uk.pool.ntp.org .POOL. 16 p- 102400.0000.000 0.002 212.23.8.6 195.66.241.2 2 u 491 10241 13.316 200.644 0.002 212.23.10.129 85.199.214.992 u 489 10241 19.929 202.213 0.002 178.79.155.116 85.199.214.992 u 491 10241 13.391 201.057 0.002 185.121.25.242 85.199.214.992 u 492 10241 14.084 200.964 0.002 81.21.65.169195.195.221.100 2 u 493 10241 17.587 200.121 0.002 178.62.6.8 68.166.61.2552 u 493 10241 13.864 200.580 0.002 Stopped monitoring, see if it stops... Thanks for your comments ___ 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.
