It can be hard to keep up to date with the latest storage jargon, so some interesting technologies can be overlooked. When it comes to home storage, the advent of USB 3 has changed the game for external storage. Suddenly, enclosures can deliver multi-gigabit performance. Or they could, if only the storage stack could handle all this new speed! That’s where a new external drive protocol, USB Attached SCSI Protocol (UASP or UAS) comes in: It allows USB-attached storage to reach its maximum potential.
Non-Queueing BOT
Back in USB 1 days, performance wasn’t really an option. Limited to 12 Mbps at “full-speed”, the bus was always the bottleneck. Plus, there really weren’t any high-speed storage devices to connect, since consumer SSD’s hadn’t yet been invented! So the designers of the USB storage stack stuck with a simple protocol for external storage devices: Bulk-Only Transport (BOT), introduced in 1999.
BOT worked well enough, given the other limitations of USB, that it remained unchanged with the advent of USB 2 in 2000. Although some devices could exceed the 480 Mbps of theoretical performance offered by “high-speed” USB 2, BOT was good enough for the simple external hard drives and thumb drives in use at the time.
But the limitations of BOT were starting to show: Since it lacked native queueing, commands were sent sequentially, causing the computer to wait for each read or write to complete before issuing another. Faster computers and faster devices meant a lot of waiting: Sometimes, the round-trip time of a storage operation was longer than it took the actual command to complete, reducing overall throughput by half or more. This is one reason that even the fastest USB 2 device has trouble exceeding 25 or 30 MB/s in real-world use.
UASP Brings SCSI to USB
Just about every operating system supports, SCSI, a full-featured and flexible storage protocol stack, but this was not available for USB devices. UASP changes that, allowing devices to use the SCSI protocol over USB. This improves performance, thanks to native command queueing, and also adds lots of other storage features like inquiry (INQ), multi-LUN configuration, and more. UASP was designed for USB 3, but it can even work with over a USB 2 connection for improved performance.
Here’s a great technical overview of UASP from usb.org: USB Attached SCSI Protocol (UASP)
For most users, UASP is all about performance. A UASP device can come much closer to the theoretical maximum throughput of the USB bus since commands no longer have to wait in a single queue. UASP separates commands, status, input, and output into four separate I/O “pipes”, eliminating the old “command, wait, response, I/O, wait, status response” cycle of BOT.
UASP is supported in the following operating systems today:
- Microsoft Windows 8 and newer “prefers” UASP if available over both USB 3 and USB 2
- Mac OS X added UASP support in OS X 10.8 “Mountain Lion” though it seems not to work reliably, especially when connected through USB hubs1
- Linux has had a UASP driver since 2.6.37 but it has been problematic and is disabled for certain hardware2
On the hardware side, UASP has been embraced by higher-end USB 3 storage controllers used by most major device manufacturers but it’s sorely lacking in low-end devices. Intel added native UASP to their Z77 motherboard PCH, but support requires an extra-cost license so some manufacturers have not enabled it.
UASP devices can be made backwards-compatible with BOT, and this new capability is auto-detected by most current operating systems, so users don’t have to worry about configuring it.
Stephen’s Stance
UASP has a lot of promise, bringing SCSI performance and features to the ever-expanding world of USB storage devices. But support has been haphazard, especially for Mac OS X and Linux, and this limits its impact. It would be nice if storage vendors could work with operating system developers to better support this storage protocol.
Does anyone know if this new UASP Protocol supports SAS drives over USB? Since the UASP Protocol supports SCSI over USB, then theoretically, if I connect a SAS to SATA adapter on a SAS drive, and plug the drive into an external UASP enabled USB HDD adapter, it should read and write to the SAS drive right? Or is the UASP Protocol some form of Quasi SCSI?
Good question. That got me thinking, since it sounds like UASP operates independent of the drive physical connector type, that it should be able to. But then I remembered all SAS storage HBA’s will also support SATA drives with an adapter, but not the other way around. You can’t plug a SAS drive into a port expecting SATA. I am curious to know what you find out.
I am still in the process of engineering the interface for this project. Stuff takes forever to come from China, especially with the Covid-19 scenario. From what I have found out so far, when you attach a SATA drive to the UASP -> USB controller, and you are running the compatible OS, it attaches to the host PC/OS as a SCSI drive.
Recently I have come across some information that states that SAS control lines use different voltages. Thus SAS can use SATA due to control line voltages being within SAS range, although not the other way around. Apparently the SAS control line voltages are higher, and SATA control adapters will not recognize the voltage difference. SAS to USB adapters cost about $500 US at the moment, so it’s worth the effort to design a more cost effective solution.
It may be possible tackling this with an alternative solution. Perhaps a mini PCI-E (such as those in notebooks etc…) can be extended externally to full size PCI-E slot capable interface. Such as those used for Bitcoin mining and external Video card usage. A PCI-E SAS controller card may then be used. Of course this is not a compact or energy saving solution, however it is a probable solution. I have a external PCI-E riser card and spare power supply, I just need to purchase a cheap PCI-E SAS controller card.
The whole thing will probably consume about 60 watts of power while in operation. HDD + Power Supply + PCI-E interface + SAS controller card. I just want to use the drives for archiving so a good sleep function setting after 10 minutes non use, should save around 95% power when not in use with a well designed and built power supply. Additionally added drives will place a 15 watt load per drive on the power supply for each additional SFF 2.5″ SAS drive used. A decent controller card can control at least 4 SAS drives. However,
Anyway, I am still researching the UASP interface, it still sounds promising, even if a separate electronic interface for the SAS -> SATA control lines need to be engineered. However, there is still most likely the issue that the SCSI commands are not interpreted at the SATA interface side of the UASP -> USB controller. This may cause the UASP controller not to even recognize incoming SCSI commands from attached SAS HDD attached to the SATA, even if control line voltages are compatible, due to the UASP controller looking specifically for a SATA not SAS HDD attached.
It’s only a pet project so it’s worth my time trying anyway.
I will post what I find out.