[time-nuts] Raspberry Pi NTP server

jimlux jimlux at earthlink.net
Thu Jul 9 17:12:22 UTC 2020 

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.

More information about the Time-nuts_lists.febo.com mailing list