Faster USB 3.0 Performance: Examining UASP And Turbo Mode

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.

Create a new thread in the US Reviews comments forum about this subject
This thread is closed for comments
52 comments
    Your comment
  • jimmysmitty
    One thing with USB is that it was never designed for massive large data thoroghputs like eHDDs and larger flash drives. And while its nice to have a faster USB standard like USB 3.0, the main idea behind USB, a single connector for peripherals like mice, KB and printer, was designed when eHDDs were almost non existent.

    Firewire was designed more with eHDDs and the such in mind and had better encoding and protocols in place to support eHDDs and such.

    Even better is Thunderbolt which has shown the ability to reach top end speeds of the attached device:

    http://www.macnn.com/reviews/elgato-thunderbolt-ssd.html

    While its a Mac based drive you can clearly see that as the size goes up (4KB->1024KB), the speed goes up which makes sense. A 4GB file will have a better average transfer rate than a 4MB file on USB, eSATA or TB. As well, it reaches almost 300MB/s read and write which is just as fast as a SATA 3Gbps SSD goes. I imagine if the drive had a better controller (say current Sandforce) it could reach 500MB/s (SATA 6Gbps speeds easily since the interface was designed with this in mind.

    So while USB 3.0 is great for where I work and such, as a lot of customers may not be able to afford eSATA or TB devices or have those on their PC, its not going to be able to keep up with demands of people who use multiple large eHDDs for data storage and thats where eSATA 6Gbps and TB will come into play. I imagine USB might just become a smaller part unless the reengineer the protocols and encoding but that might also kill any backwards compatibility it has currently.
    2
  • forestie
    Overall, good article.

    However, it seems the author didn't look very far regarding USB attached SCSI protocol on Linux: a simple Google search: "uas protocol usb attached scsi linux" gives the first link: "http://cateee.net/lkddb/web-lkddb/USB_UAS.html", which teaches us that UAS support is available since Linux kernel 2.6.37 and enabled by option "CONFIG_USB_UAS".

    I suppose it is a safe bet to assume that most modern distributions ship with this option enabled, as is often the case with Linux distributions; they tend to provide almost all the kernel modules "just in case".
    9
  • forestie
    By the way, I am not 100% sure but I think the correct name is "USB attached SCSI", not "USB attached serial". I had to put the proper term in my aforementioned Google search.

    In Linux terminology, USB attached serial seems to correspond to USB-to-serial adapters (RS-232, aka COM/serial port).
    0
  • merikafyeah
    This article says that the Syba SD-PEX20122 card has ASM1042 controller hardware, yet Syba's site and everywhere else says that this card is based on "VLI VL80x USB 3.0 Host Controller IC". Is this referring to something else, or has Syba switched to a different controller since the time this article was written?

    EDIT: Nevermind, the article linked to the wrong card but referenced the correct model number. The model referenced was SD-PEX20112, which does include the ASM1042 controller. The model the link sends you to is SD-PEX20122, which has the VLI VL80x chipset.
    This is the correct link: Syba SD-PEX20112

    Recap:
    Syba SD-PEX20112: Based on Asmedia ASM1042 USB 3.0 Host Controller IC
    Syba SD-PEX20122: Based on VLI VL80x USB 3.0 Host Controller IC
    (This model includes a 20-pin header for up to 2(two) additional external USB 3.0 connectors on newer cases which can be used simultaneously with the rear connectors, so this is technically a 4-port card and is the better deal IMO, but I digress.)

    P.S. I noticed another typo on page 4:
    Quote:
    However, Asus is alone in supporting UAS in Windows 7, and it does so through by licensing MCCI's ExpressDisk UASP Driver.


    BTW, very interesting article. USB is well underway to being one of two "be-all-end-all" connectors for consumer tech of the future. The second of course, being HDBaseT. USB is so ubiquitous that it can't be overtaken. However, the same cannot be said for FireWire/eSATA/Thunderbolt/HDMI/DVI etc, which have all been made obsolete by the existence of HDBaseT. Once HDBT penetrates the market, only USB will stand a chance at remaining relevant.
    0
  • acku
    merikafyeahThis article says that the Syba SD-PEX20122 card has ASM1042 controller hardware, yet Syba's site and everywhere else says that this card is based on "VLI VL80x USB 3.0 Host Controller IC". Is this referring to something else, or has Syba switched to a different controller since the time this article was written?EDIT: Nevermind, the article linked to the wrong card but referenced the correct model number. The model referenced was SD-PEX20112, which does include the ASM1042 controller. The model the link sends you to is SD-PEX20122, which has the VLI VL80x chipset.This is the correct link: Syba SD-PEX20112Recap:Syba SD-PEX20112: Based on Asmedia ASM1042 USB 3.0 Host Controller ICSyba SD-PEX20122: Based on VLI VL80x USB 3.0 Host Controller IC


    Sorry for the confusion. We made a typo. It happens to us all. :)

    Cheers,
    Andrew Ku
    TomsHardware.com
    2
  • A Bad Day
    My main problem with my NEC USB 3.0 (first generation i7 laptop)?

    It won't accept USB 2.0 flash drives, and I only have USB 2.0 flash drives.

    Derp.
    3
  • sickbyreputation
    usb 3 is for small transfers because it boost small files transfer speed and on large files they slow down to normal 2.0 speed anyway your best bet is sdd to sdd with esata and teracopy is a great app file file transfer copied 78gb in 3 1/2 min from main system ssd to hotswap sdd
    -4
  • TeraMedia
    Outstanding article. This is the kind of information that can help make the difference between an informed purchase and a regrettable one, and keeps the manufacturers innovating. I hadn't even heard of UASP, but now I know to look at the specs before I buy any USB 3.0 storage devices, motherboards or add-in USB 3.0 cards, to verify this latent feature.

    Off-topic, but an article request with similar technical analysis requirements:
    It would be great if you could do a similar analysis for lossless audio streaming over HDMI - i.e. Dolby TrueHD and DTS Master Audio - on a handful of different current-gen chipsets and GPUs, and explain why some work and others don't.
    2
  • jn77
    I think the joke comes in here where the USB Fanboys that hate Firewire need to re-think what they were talking about with USB2.0.

    While by spec, Firewire 400 or 800 was "slower" than USB 2.0, why did all my FireWire devices transfer data at speeds almost double what USB 2.0 did? Because its all jargon on paper. FireWire actually had a good protocal and in reality, transfered date faster than USB ever did. We really need FireWire 3200, 6400, 12,800, etc. USB was always a replacement for PS/2 connectors.
    1
  • LukeCWM
    jn77While by spec, Firewire 400 or 800 was "slower" than USB 2.0, why did all my FireWire devices transfer data at speeds almost double what USB 2.0 did?


    Somewhere at sometime, I read an article that indicated that Firewire 400 is 400 Mb/s per channel, while USB 2.0 is 480 Mb/s shared for all channels. So the more devices you have plugged in, the more your bandwidth suffers. Hopefully someone more educated than I or with more time to research will clarify this.
    2
  • Bob55
    Figures that Linux has support already, most of the under-the-hood stuff is 'just there' very rapidly.
    I had a Firewire to SCSI adapter, as Firewire's protocol is SCSI based. The details were what made it nearly useless, too much effort would be needed to fix the last 5% or so. I suspect a UASP to SCSI adapter would have similar problems. Too bad, I'd love to 'just plug in' old hardware to current machines.
    1
  • A Bad Day
    jn77I think the joke comes in here where the USB Fanboys that hate Firewire need to re-think what they were talking about with USB2.0.While by spec, Firewire 400 or 800 was "slower" than USB 2.0, why did all my FireWire devices transfer data at speeds almost double what USB 2.0 did? Because its all jargon on paper. FireWire actually had a good protocal and in reality, transfered date faster than USB ever did. We really need FireWire 3200, 6400, 12,800, etc. USB was always a replacement for PS/2 connectors.


    USB was originally designed as a simplistic low-cost system. Keyboards, mouses, printers, other low-bandwidth devices.

    Firewire was designed for video and audio transmission, which eat up large amount of bandwidth.

    It was expected of USB to catch up to Firewire, especially since they have a much larger marketshare than Firewire.


    In the electronic markets, hardware/software quality of a product makes some difference. But they're useless if barely anyone are using such product.
    3
  • palladin9479
    Anonymous said:
    Somewhere at sometime, I read an article that indicated that Firewire 400 is 400 Mb/s per channel, while USB 2.0 is 480 Mb/s shared for all channels. So the more devices you have plugged in, the more your bandwidth suffers. Hopefully someone more educated than I or with more time to research will clarify this.


    FW used a protocol very similar to SCSI and devices were daisy chained. Bandwidth per channel was shared across the entire chain yet rarely did you have more then one device plugged in per channel. USB's bandwidth is shared per controller, most controllers had an internal wired hub that branched into two to four ports on the motherboard. Later controllers actually had full dedicated bandwidth per channel and abstracted to the OS multiple controllers.

    Ultimately the primary difference between USB and FW (or eSATA) is DMA mode support. USB does not support DMA transfers, thus the CPU has to fork life the data from the USB controllers I/O buffer into main memory and back again. FW / eSATA both support DMA and can transfer it from the controllers I/O buffer into main memory without assistance from the CPU. This has a significant impact on random access times and transfers along with how much load the CPU is placed under. This is why I'd never support a permanent storage solution on USB, it's good for hot-swapping devices for sneaker-netting data or data-on-the-go but is horrible for any sort of storage expansion. UAS seems to be an attempt to introduce the SCSI like features of SATA / FW to the USB protocol which should help, though without DMA support on the host controller it's always going to have issues.
    2
  • Nspace
    "ASMedia's hardware does offer UAS support, while Renesas' doesn't"

    A few months ago Renesas launched controllers: μPD720201 and μPD720202
    http://www.theinquirer.net/inquirer/news/2032896/renesas-launches-usb-controllers

    While the older Renesas USB 3.0 controller is μPD720200.
    May you confirm whether you tested the newest Renesas controller?
    0
  • Crashman
    A Bad DayMy main problem with my NEC USB 3.0 (first generation i7 laptop)?It won't accept USB 2.0 flash drives, and I only have USB 2.0 flash drives.Derp.
    Easy answer: Fix your broken laptop. Option 2: Send it in for repair. Option 3: Throw it away. Really, there's something broken.

    Look at it this way: USB 3.0 and USB 2.0 use separate PINS. They're separate signals. You can run a single port with BOTH Intel's USB 2.0 controller and the NEC/Renesas USB 3.0 controller connected to those different pin sets. So there's no excuse for your problem, and it can't be blamed on NEC.

    Maybe you need to enable USB storage in BIOS or something. Or maybe the people who engineered your laptop had a brain fart. Either way, it's a broken laptop not a controller issue.
    1
  • LordConrad
    Does Acronis True Image Home 2012 have USB "Turbo Mode" enabled by default? I would love to have a bootable True Image CD that uses Turbo Mode for faster drive imaging.
    0
  • aries1470
    Can you please correct your comment:
    Quote:

    "With a maximum throughput of 1.5 MB/s, file transfers over USB 1.1 were frustratingly slow,"

    That comment is incorrect. The "Low Speed" was 1.5 MB/s, but the full speed of USB 1.1 was 12 MB/s. USB 2.0 introduced the 480 MB/s.

    Please correct it, as it gives the wrong image. Also, the 1.5 MB/s was associated with 1 token of power, that equaled 100 mA, while the 12 MB/s devices could ask for the full 5 of which is 500 mA. Also, there lies the other obstacle of low power devices being limited to 3mtr cables compared to 5mtr unpowered cables for the 500 mA.
    -2
  • Crashman
    aries1470Can you please correct your comment:That comment is incorrect. The "Low Speed" was 1.5 MB/s, but the full speed of USB 1.1 was 12 MB/s. USB 2.0 introduced the 480 MB/s.Please correct it, as it gives the wrong image. Also, the 1.5 MB/s was associated with 1 token of power, that equaled 100 mA, while the 12 MB/s devices could ask for the full 5 of which is 500 mA. Also, there lies the other obstacle of low power devices being limited to 3mtr cables compared to 5mtr unpowered cables for the 500 mA.
    You're confusing bits and Bytes. 12 Mb/s ***IS*** 1.5 MB/s
    1
  • aries1470
    CrashmanYou're confusing bits and Bytes. 12 Mb/s ***IS*** 1.5 MB/s

    Thank you for pointing it out.
    Buuuuttt... just to get it in ;-)
    Low Speed (1.5 Mbit/s)
    Full Speed (12 Mbit/s)
    Hi Speed (480 Mbit/s)

    Note to self: Pay more attention to the b :-)
    0
  • edlivian
    Ok, so all I have to do is buy a syba SD-PEX20112, and the ASUS ASM1042 driver and I am golden?

    Or do I also need to have the card on an asus board/change bios string to match asus?
    1