As we've mentioned, even if you have a UAS-capable device, the system you plug it into must still support the feature before it offers any appreciable benefit. Getting there requires software and hardware considerations.
Addressing The Software Side

Windows 7's driver stack doesn't include UAS support, which is why Asus' USB 3.0 Boost utility includes .inf driver configuration files in a sub-installation folder. These driver configuration files are the missing link.
As it turns out, you can technically use those same drivers to enable UAS support manually. There's one big roadblock in the way, though. When Asus licensed MCCI's UAS driver, it included a subroutine that checks the make and model of your motherboard. If you're not using one of the company's boards, the process becomes prohibitively complex (although we've made it work in our lab).

If, however, CPU-Z identifies the manufacturer of your motherboard as "ASUSTek Computer INC", manually replacing the "USB Mass Storage Driver" with "ASUS USB 3.0 Boost Storage Driver" under System Properties reveals a second "UAS Storage Driver."
Try this on a non-Asus motherboard and you'll get a driver error, unfortunately, and the second driver remains hidden. The only way to work around the error is modify your SMBIOS string using a special tool. Again, it's probably more of an effort than most people want to even bother with, particularly since we aren't even done yet.
To be clear, then, we're only able to proceed with an older Asus board that does support USB 3.0, but isn't already UAS-enabled.
Addressing The Hardware Side

Just because we have the driver installed doesn't mean UAS is working yet. The right hardware matters, too. Take Asus' P8P67 Deluxe as an example. It contains the right SMBIOS string, naturally, but it employs a Renesas USB 3.0 controller, which is why it's not listed on the support page for USB 3.0 Boost. What all of the supported boards do have in common is ASMedia's ASM1042 controller.
The implication is that ASMedia's hardware does offer UAS support, while Renesas' doesn't. We were able to get UAS working through the Z77 chipset's native USB 3.0 ports using Windows 8 on an ASRock's Z77 Extreme6 motherboard (along with the Asus UAS driver on the Z77-equipped P8Z77-V Deluxe), suggesting that Intel's integrated controller does support UAS.
In contrast, the older Renesas controller either lacks the necessary hardware support or it requires a driver update.

The answer, interestingly enough, is to buy a Syba USB 3.0 PCIe card (SD-PEX20112). This cheap solution works because it centers on the ASM1042 controller hardware, which supports UAS, according to ASMedia. Simply install ASM1042 driver from Asus, and you're good to go.

Running Iometer with the Thermaltake BlacX 5G plugged into our Syba USB 3.0 card confirms that UAS works; sequential read speed tops out at 325 MB/s, which is right where we'd expect to see it on a board with native UAS support.
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.
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".
In Linux terminology, USB attached serial seems to correspond to USB-to-serial adapters (RS-232, aka COM/serial port).
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:
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.
Sorry for the confusion. We made a typo. It happens to us all.
Cheers,
Andrew Ku
TomsHardware.com
It won't accept USB 2.0 flash drives, and I only have USB 2.0 flash drives.
Derp.
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.
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.
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.
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.
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.
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.
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?
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.
"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.
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 :-)
Or do I also need to have the card on an asus board/change bios string to match asus?