[time-nuts] Raspberry Pi NTP server

Thu Jul 9 18:59:41 UTC 2020

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 <jimlux at earthlink.net> 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 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 <Stromeko at nexgo.de> 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 u    7   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 at 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 at 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 at 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 at lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>