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 <[email protected]> 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 -- [email protected]
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
