3
\$\begingroup\$

How could I determine the latency involved with transmitting data on a USB to EIA-485 converter?

The converter is a B&B Electronics USOPTL4 using the FTDI chip, and I know that there is a throughput latency from the time my Windows application calls WriteFile and data is actually transmitted.

The same question applies on the reception end of things. I know there's a latency from when the FTDI receives the serial data and it's provided to the OS for reading.

Has anyone successfully measured these latencies?

\$\endgroup\$
3
\$\begingroup\$

"How could I determine the latency"?

I use an oscilloscope to determine typical latencies.

I investigate the source code and hardware to get a conservative estimate of the worst-case latency.

typical latency

If I had to measure the typical transmit and receive latency of some particular setup, I'd start with the simplest measurement: typical round-trip delay. Perhaps something like this would be relatively easy to set up:

  • Software on the Arduino turns on an LED, and then immediately sends a message out the UART
  • you have the UART pins connected to the appropriate level-shift IC connected to your USB to EIA-485 converter.
  • Software on the PC waits for serial input, and then immediately send a short response message
  • Software on the Arduino waits for serial input, and then immediately turn on another LED.
  • Software on the Arduino waits some random time, turns off all the LEDs, waits some more random time, then starts over with turning on the first LED.

  • you connect the o'scope up to the 2 LEDs and measure the typical delay between the first LED turning on and the second LED turning on.

  • you recompile with different message sizes; make a graph of message size vs. typical delay.

worst-case latency

A real-time system must have bounded worst-case latency. Alas, that doesn't seem possible with Windows -- even if you could get the source code for Windows, a device-driver patch next week might add another 2 milliseconds of worst-case latency.

Some real-time operating systems support USB -- in particular, EMC running on Linux running on RTAI supports USB -- hidcomp, Custom USB input device with emc, etc. USB has a "isochronous transfers" and "interrupt transfers" that seem like they could be useful for bounding worst-case latency. Alas, no one seems to trust USB for real-time tasks: EMC2 Supported Hardware, Real time USB control?, USB problems, etc.

So EMC2 still uses parallel ports to get known worst-case latency; other low-latency communication protocols use a variety of hardware including Ethernet hardware.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ It would likely be more cost effective and accurate to acquire the data by measuring from the PC software through serial loopback back to the PC software - you need no more equipment than a scrap of wire, and you can collect all the data to measure the statistical frequency of the outliers. If you had a separate low-latency output channel from the PC you could us the scope to measure one-way delay relative to that, but short of hacking low level video or IDE drivers that kind of thing may not be available in modern PCs. \$\endgroup\$ Oct 6 '12 at 17:14
  • \$\begingroup\$ @ChrisStratton: Excellent suggestion. I'm not sure how much effect the additional "get timestamp" routine will have, but I suspect it is insignificant compared to the latency and jitter of USB. \$\endgroup\$
    – davidcary
    Oct 10 '12 at 3:05
1
\$\begingroup\$

Well, what you are trying to do?

What you're going to find is that every level in that stack adds a variable amount of seemingly random latency. While it may be usually under 1 ms, it is likely to occasionally be much much greater than that.

The OS itself is going to have some random multitasking scheduler latency. That could be 0-50 ms (or more on specialized or poorly configured systems). If you're trying to do something with very tight timing constraints, you will likely need to do it in a custom device driver in kernel space to make timing.

After that, USB isn't a very latency-friendly bus. Waiting for USB to send the data out is going to add a small random latency. The reading side is actually a little worse... as the USB root must poll connected devices to see if they have data. I can't give you much on what the ranges on these delays are... maybe someone else can help here. However, it's likely to be pretty variable depending on stuff like if you're connecting though a hub and how many other devices are attached. So, if you measure it yourself make sure you try at least a few USB device combinations. Try it with webcams and thumb drives attached and active, through a hub and direct, etc.

\$\endgroup\$
1
  • \$\begingroup\$ I'd amplify @darron's point, If latencies matter enough to be worth measuring ( say, 10's of ms) , USB going to be more trouble than it is worth. If deterministic timing is required, your architecture gets pushed away from consumer interface like USB. \$\endgroup\$ Jun 15 '11 at 1:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.