So, What Makes USB 3.0 Slower Than We Expect?
So, why do our USB 3.0-based devices sputter out around 150 MB/s when the interface is supposed to be good for up to 500 MB/s or so? Breaking down the basic speeds and feeds is a good first step in understanding the inner workings of USB.
| Interface | Data Rate (Bits/s) | Theoretical Bandwidth (Bytes/s) | Theoretical Bandwidth After 8b/10b Encoding (Bytes/s) |
|---|---|---|---|
| USB 2.0 | 480 Mb/s | 60 MB/s | 48 MB/s |
| USB 3.0 | 5 Gb/s | 625 MB/s | 500 MB/s |
Because USB isn't ideal for transmitting baseband data, information needs to be encoded using a line code and then decoded on the other end. This is a critical step that allows the receiving end to recover the data clock. Without it, you end up with a much higher error rate. Like many other interfaces (like optical gigabit Ethernet), USB uses the 8b/10b line code, turning eight-bit symbols into ten-bit symbols, achieving what is referred to as DC balance. Although 8b/10b provides the frequent transitions needed for clock recovery, it incurs a 20% bandwidth hit.
Right off the top, then, USB 3.0's 5 Gb/s data rate turns into a 500 MB/s peak throughput. But that's not the only variable eating into your device's real-world transfer speeds.
The USB Implementers Forum (USB-IF) states the following in its Universal Serial Bus 3.0 Specification, under section 4.4.11:
SuperSpeed efficiency is dependent on a number of factors including 8b/10b symbol encoding, packet structure and framing, link level flow control, and protocol overhead. At a 5 Gbps signaling rate with 8b/10b encoding, the raw throughput is 500 MBps. When link flow control, packet framing, and protocol overhead are considered, it is realistic for 400 MBps or more to be delivered to an application.
All of the sudden, USB 3.0 is down another 100 MB/s. Even at 400 MB/s, though, we're still looking pretty good compared to USB 2.0's sub-40 MB/s performance.
Although those figures help temper our expectations of USB 3.0 somewhat, they don't answer why we're seeing real-world numbers that are so much lower, though. We're still left asking, "Why are the USB 3.0 devices so slow when the spec is capable of so much more?"
The first answer to our question is that the device-side controller significantly influences performance. In the chart above, Thermaltake's BlacX 5G is clearly capable of overtaking Apricorn's SATA-to-USB 3.0 Adapter, though you're only going to see those numbers if you use a high-performance SSD. More impressively, the BlacX 5G is capable of outperforming Buffalo's external RAID solution, which shows up in the chart above that. Now, the BlacX 5G is the only device of the three mentioned that uses an ASM1051 controller. Thus far, in our experience, USB 3.0 devices employing ASMedia controllers deliver the best performance. But that advantage alone isn't enough to push past 300 MB/s to the interface's peak potential.
Second, the host's controller significantly influences performance. The aforementioned benchmarks were run on an ASRock Z77 Extreme6 motherboard’s native USB 3.0 ports. With that said, we've seen conflicting performance numbers, and the results almost seem to be implementation-specific. Etron's controller on one board tops out at 250 MB/s, and then the same controller on another platform can't get past 200 MB/s. Overall, though, the most consistent experience comes from USB native to a Platform Controller Hub or Fusion Controller Hub.
The final issue is that, although USB 3.0 is capable of 400 MB/s, its performance potential is impeded by an inefficient protocol. All forms of USB use four transfer types: control, interrupt, isochronous, and bulk. The first two—control and interrupt—define the manner in which the host communicates with devices. The third transfer type, isochronous transfer, is for transferring data periodically and continuously, determining how a device can reserve a defined amount of bandwidth with guaranteed latency. Isochronous transfer is typically used in audio/video devices like capture cards, because it resolves the problem of data loss (such as video frame dropping) when multiple USB devices are in use. Lastly, bulk transfer (bulk-only transport) is the mode that we are focusing on here, since it's used for transferring data to USB mass storage devices.
Bulk-only transport—or “BOT” as it's more commonly known in engineering circles— was originally developed in 1998 for USB 1.1 as a protocol that receives and processes a single command at a time. BOT was specifically conceived to handle the needs of USB thumb drives, which at the time were quite small with low speed/capacity. In this respect, BOT is similar to native IDE in that command queuing is dropped on the host side (that explains why USB performance flatlines when queue depth is increased).
BOT remained unchanged when USB 2.0 debuted in 2000, possibly because the USB bus speed bottleneck eliminated any need for a BOT update. But that might have been a mistake in retrospect. This little bit of procrastination has a big impact on USB 3.0 because the interface is no longer slower than the devices connecting to it. Now, the reverse is true.
