33

First up, I don't know much about USB, so apologies in advance if my question is wrong.

In USB 2.0 the polling interval was 0.125ms, so the best possible latency for the host to read some data from the device was 0.125ms. I'm hoping for reduced latency in USB 3.0 devices, but I'm finding it hard to learn what the minimum latency is. The USB 3.0 spec says, "USB 2.0 style polling has been replaced with asynchronous notifications", which implies the 0.125ms polling interval may no longer be a limit.

I found some benchmarks for a USB 3.0 SSDs that look like data can be read from the device in just slightly less than 0.125ms, and that includes all time spent in the host OS and the device's flash controller.

http://www.guru3d.com/articles_pages/ocz_enyo_usb_3_portable_ssd_review,8.html

Can someone tell me what the lowest possible latency is? A theoretical answer is fine. An answer including the practical limits of the various versions of Linux and Windows USB stacks would be awesome.

To head-off the "tell me what you're trying to achieve" question, I'm creating a debug interface for the ASICs my company designs. ie A PC connects to one of our ASICs via a debug dongle. One possible use case is to implement conditional breakpoints when the ASIC hardware only implements simple breakpoints. To do so, I need to determine when a simple breakpoint has been hit, evaluate the condition, if false set the processor running again. The simple breakpoint may be hit millions of times before the condition becomes true. We might implement the debug dongle on an FPGA or an off-the-shelf USB 3.0 enabled micro-controller.

Andrew Bainbridge
  • 4,651
  • 3
  • 35
  • 50

4 Answers4

24

Answering my own question...

I've come to realise that this question kind-of misses the point of USB 3.0. Unlike 2.0, it is not a shared-bus system. Instead it uses a point-to-point link between the host and each device (I'm oversimplifying but the gist is true). With USB 2.0, the 125 us polling interval was critical to how the bus was time-division multiplexed between devices. However, because 3.0 uses point-to-point links, there is no multiplexing to be done and thus the polling interval no longer exists. As a result, the latency on packet delivery is much less than with USB 2.0.

In my experiments with a Cypress FX-3 devkit, I have found that it is easy enough to get an average round trip from Windows application to the device and back with an average latency of 30 us. I suspect that the vast majority of that time is spent in various OS delays, eg the user-space to kernel-space mode switch and the DPC latency within the driver.

Andrew Bainbridge
  • 4,651
  • 3
  • 35
  • 50
  • 4
    Andrew, me and my project group have the same question as you had. We are also testing the roundtrip time with the Cypress FX-3, but can not seem to achieve the same results as you did. Did you conduct your test with a single packet or with a stream of data and which transfer mode did you use? Could you maybe point us in the right direction? – supdun May 11 '15 at 15:14
  • 2
    We are really wondering how you achieved this result, we can't achieve a latency of 30 us because we are stuck at a latency of 50 us. – supdun May 27 '15 at 10:46
  • 1
    Andrew, can you link to any resources that helped you achieve this? Do you have a whitepaper or more info on the final solution? E.g. was the driver more critical and OS dependent? – Paamand Jul 02 '19 at 13:14
  • @Paamand - Sorry no. Its a while ago and I don't remember the details. I think I just used some simple example code from the Cypress SDK and ran on a Dell laptop probably running Windows XP. I can't remember where the driver came from. – Andrew Bainbridge Jul 02 '19 at 18:12
  • 3
    @supdun - Ok. The reason for asking is that is seems to contradict the USB 3.0 specification where it can adjust the uSOF from 125us by not more than -13.33us. E.g. I would not expect it possible to achieve < 111us average. Are you sure of your conclusion? Can you add comment or update answer with description of how? – Paamand Jul 12 '19 at 11:12
  • 1
    I don't understand how USB3 isn't anymore multiplexed on electrical layer. There's only 4 wires (to and back, differential), how is that not multiplexing when there's more than two devices? – Johannes Schaub - litb Dec 22 '22 at 12:06
7

I've got a couple of resources for you, one I've just downloaded which is the complete specs ... several pdfs zipped up for USB3, and here is short excerpt from page 58,59 (USB 3_r1.0_06_06_2011.pdf):

USB 2.0 transmits SOF/uSOF at fixed 1 ms/125 μs intervals. A device driver may change the interval with small finite adjustments depending on the implementation of host and system software. USB 3.0 adds mechanism for devices to send a Bus Interval Adjustment Message that is used by the host to adjust its 125 μs bus interval up to +/-13.333 μs.

In addition, the host may send an Isochronous Timestamp Packet (ITP) within a relaxed timing window from a bus interval boundary.

Here is one more resource which looked interesting which deals with calculating latency.

You make a good point about operating system latency issues, especially in not real time operating systems.

I might suggest that you check on SuperUser too, maybe someone has other ideas. CHEERS

leeo
  • 148
  • 10
happy coder
  • 1,517
  • 1
  • 14
  • 29
  • Unfortunately the link is dead, edit queue is full again. You could link to the doc overview instead: https://www.usb.org/documents – mashuptwice Jul 27 '22 at 14:16
2

I dispute the marked answer.

On Windows there is no way to achieve the stated roundtrip latency over USB. SuperSpeed (3.0) or not. The documentation states:

The number of isochronous packets must be a multiple of the number of packets per frame.

https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/transfer-data-to-isochronous-endpoints

The packets per frame is given by the bIntervaland also determines the polling interval. E.g. if you want to achieve a transfer every microframe (125usec) you will need to submit 8 transfers per URB (USB Request Block), which means a scheduling service interval of 1ms.

Anything else requires your own kernel-mode driver or is out-of-spec.

On RT Linux I can confirm roundtrips of 2*125usec + some overhead.

Paamand
  • 626
  • 1
  • 6
  • 17
1

Excerpts from embedded.com: "USB 3.0 vs USB 2.0: A quick reference summary for the busy engineer"

Communication architecture differences USB 2.0 employs a communication architecture where the data transaction must be initiated by the host. The host will frequently poll the device and ask for data, and the device may only transmit data once it has been requested by the host. The high polling frequency not only increases power consumption, it increases transmission latency because the data can only be transmitted when the device is polled by the host. USB 3.0 improves upon this communication model and reduces transmission latency by minimizing polling and also allowing devices to transmit data as soon as it is ready.

...

Timestamp enhancements

Unlike USB 2.0 cameras, which can range in accuracy from 0 to 125 us, the timestamp originating from USB 3.0 cameras is more precise, and mimics the accuracy of the 1394 cycle timer of FireWire cameras.

...

USB 3.0 -- or Super-speed USB -- overcomes key limitations of other specifications all these limitations with six (over IEEE 1394b) to nine (over USB 2.0) times higher bandwidth, better error management, higher power supply, ... and lower latency and jitter times.

P.S. also it says about "longer cable lengths" for USB 3.0, but other paragraph contradicts to this & says upto 5m for USB 2.0, upto 3m for USB 3.0.

Nishi
  • 10,634
  • 3
  • 27
  • 36