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.
