UASP makes Raspberry Pi 4 disk IO 50% faster




What's UASP, you might ask?

Without UASP, a drive is mounted as a Mass Storage Device using Bulk Only Transport (or BOT), a protocol that was designed for transferring files way back in the USB 'Full speed' days, when the fastest speed you could get was a whopping 12 Mbps!

With USB 3.0, the BOT protocol cripples throughput. USB 3.0 has 5 Gbps of bandwidth, which is 400x more than USB 1.1. The old BOT protocol would transfer data in large chunks, and each chunk of data had to be delivered in order, without regard for buffering or multiple bits of data being able to transfer in parallel.

So a new protocol was created, called 'USB Attached SCSI Protocol', or 'UASP'.

I won't get too technical here, but the SCSI protocol has been around for a very long time—long enough that it was part of a joke in this 1994 Dilbert comic. It has features like allowing parallel bits of data to be copied and out of order data transfer so the drive can use buffering and caching mechanisms for better performance.

Around the time USB 3.0 was introduced, most USB storage devices and adapters for hard drives started adopting the standard. And some computers with only USB 2.0 ports could have their firmware updated to use UASP for newer drives, so some USB 2.0 connections got a speed boost.

What does this have to do with the Pi?

Let's not get too far ahead of ourselves. Going back to Brad's comment on my Pi SSD video, I replied to Brad that I didn't even realize I had the non-UASP version of the Inateck case.

So I ordered the UASP version, and waited for it to arrive.

Inateck USB 3.0 SATA case - top side

And when it did arrive, I tried to see what was different about it. The top, sides, and back are completely identical.

Inateck USB 3.0 SATA case with and without UASP - bottom side

On the bottom, the only difference is one additional letter in the model number.

Inateck USB 3.0 SSD SATA adapter circuit boards - UASP

The differences are only really apparent if you take the thing apart and look at the actual circuit board. The older non-UASP version is on the top left in the picture above, and the UASP version on the bottom right. The UASP version has a completely different layout, and uses a different controller chip.

If you have a USB drive and don't want to take it apart and look up the specs of the controller chip, the only reliable way to tell if it's being mounted with UASP support or not is to plug it into your Pi, then run the command lsusb -t:

$ lsusb -t

This command lists all the USB devices in a tree, and for each of the hard drives, you should see a Driver listed. If it's uas (like in the above example), then your drive supports UASP and you'll get the best speed. If it's usb-storage, then it's using the older BOT protocol and you won't see the full potential.

I also had two other old SATA adapters that I've used over the years when doing computer repairs, when I would clone an old hard drive to a new one, or try to recover data from a hard drive in a broken computer.

I checked this inland adapter I bought from Micro Center, and it also supports UASP, which was a surprise since the specs on Micro Center's website showed the data transfer rate as "Up to 480Mbps", ha!

Then I checked this StarTech SATA adapter I bought in 2015 and it also supports UASP. So it looks like most newer USB 3.0 adapters do support it, but it's not always easy to see in the specs on Amazon or other retailers' websites.

Update: I also bought a cheap Sabrent adapter when it was on sale last week, and it also works with UASP on my Pi 4.

What about the Pi 3 B+ and older Pis?

Even though Raspberry Pis older than the Pi 4 only have USB 2.0 ports, I wanted to check if they might support UASP, because as we'll see in a minute, just having UASP versus the older BOT protocol makes a large difference in performance, which would help even on older USB 2.0 ports.

Alas, after testing with all my adapters, I found they all mounted the drive using the usb-storage driver. I was trying to find any official confirmation as to whether the Pi 3 B+ firmware could support UASP, but all I could find was a reference in this Pi Forum post to the Pi's dwc_otg driver not having support for a feature the UAS driver requires.

So if you have an older Raspberry Pi, your options for fast external storage are very limited. I'd stick with the Pi 4 if you want to do anything that requires data transfer like building a NAS, setting up Nextcloud, using it for backups, or media streaming.

Benchmarks with and without UASP

These benchmarks show just how big a difference UASP makes when you use it with a drive on a Raspberry Pi 4.

Raspberry Pi 4 USB 3.0 UASP performance difference

Across the board, UASP makes a huge difference. At the top there are benchmarks for hdparm and dd tests, which test large file transfers. These show 50% and 40% speedups, respectively.

At the bottom there are 4K random access benchmarks, which are a better measure of how the drive will perform doing typical computing tasks. And UASP still makes a big impact. Random reads are 35% faster, and random writes are 20% faster.

But I wanted to check something else, too. With more efficient data transfer possible, would there be any measurable difference in how much power is required?

For many Raspberry Pi projects, efficient power usage is an important consideration, especially if you're running the Pi off a battery or solar energy.

UASP power consumption benchmark on Pi 4

I used a Satechi USB-C power tester and measured an 8% peak power savings using UASP. That means you'd get 8% more runtime on a battery if you do a lot of file transfers.

As with all my benchmarks, I ran every benchmark four times, discarding the first result. I talked a lot about my benchmarking process in my previous Raspberry Pi Cluster video.

You can also see all the raw data and my methodology in this benchmarking issue on the turing-pi-cluster repository. If you run the same benchmarks, you may get slightly different results if you use a different SSD or enclosure.


My advice is always use UASP with USB 3.0 devices on the Pi 4, otherwise you're missing out on a pretty substantial performance gain. Also, remember to plug USB 3.0 devices into the blue USB 3.0 ports, not into the black USB 2.0 ports, otherwise you won't see any of the performance difference.


Super interesting, thanks for sharing. A while back I set my RPi4 up to boot via USB using James A. Chambers' guide
(…) and ran into stability and consistent booting issues even though the enclosure I bought was on the "OK" list but wasn't showing the right controller chip. Ultimately I had to switch from that enclosure to a Samsung T5 USB drive I had lying around and everything has ran without a hitch ever since. I wonder if this might have been a factor as I don't think it was UASP-supported controller since it wasn't the ASMedia chipset I expected.

The linux kernel holds a list of sata->usb bridge devices that behave unexpectedly when using the uas driver. If the deviceID, taken from lsusb for example, matches any of the the ones in the list, the quirks will be activated. "Storage Quirks" is what this is referred to in the kernel.
The kernel src file is… .

Upon uas detection, explained in kernel src /drivers/usb/storage/uas-detect.h , there is a comment section in the middle mentioning ASMedia chipset detection based on deviceIDs. Line 80 states "ASM1153 - with working uas support"

Thanks for these infos, I am hosting Nextcloud on my Pi4 and I was looking for an external enclosure to use for my hard drives but I was looking for more info regarding performance differences between UASP and non UASP devices. It would be interesting to have a performance comparison between USB3 devices on the Pi4 and a regular computer and the performance differences between a Hard Drive inside a USB3 enclosure and the same Hard Driveconnected to a SATAIII port.

Don’t activate encryption on such an unreliable contraption. I know “everyone is doing it” lol Inwould like to see a survey of people who corrupted their data using non-ECC memory, shorting SD-cards, thermal nightmares exacerbated by high CPU loads during encryption and cable/controller power mismatches. Use DigitalOcean or something (may want to note that hosting personnel can get at your encrypted files unless you use currently experimental end-to-end encryption or other precautions.)

Great article!


I don't believe the conclusion in the second sentence justifiably follows from the first, perhaps "up to 8%" is more correct here?

True... but by "if you do a lot of file transfers" I mean that if you have a Pi that's constantly doing things like storing or reading files from it's main drive (I have some Pis that do remote time-lapse photography where this is the case) then it could see the an 8% improvement, best case.

Won't you potentially get *more* than 8% more runtime? Since the transfer goes more quickly, the (peak) power draw lasts a shorter amount of time, too.

Sorry, but is this news? UASP has been available for >5 years, and behaves pretty much the same on all platforms.

The real mystery is why USB flash sticks don't routinely provide UASP. The manufacturers seem to think that the market only ever uses them as modern-day floppies (sneakernet, really).

The Pi 4 is the first of the Raspberry Pis to support uasp. And that wasn't really directly disclosed to us! That's what the news is. The rest is basically testing uasp and seeing just what all the hubub was about!

Still a good technical write-up!

I have a HDD enclosure with JMS567 chipset, which supports UASP, however, on my Pi 4 it's using the usb-storage driver. Anyone experiencing that with this chipset as well, or any suggestions on how to get it working with uasp?

I actually have the same issue.

Specs: I have this 5 bay 3.5 HDD enclosure: which uses JMicron's chipsets: JMS567+JMB575

And though the specs say the enclosure's chipsets support UASP Protocol, lsusb -t does not indicate this, but instead Driver=usb-storage is used:

$ lsusb
Bus 002 Device 003: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge

$ lsusb -t

check my comment from above about storage quirks. Your deviceId is in the kernel's internal quirks list. According to the src code, your chip doesnt handle FUA properly, which is required for uasp to work. If you still wanna try, you may have to recompile the kernel.

Is the speed increase consistent with booting from the drive as just mounting it for extra storage?

Yes, that was my experience. I booted from the drive and it appeared as uas, but I also plugged it in when booting from microSD cards, and it still showed as uas.

I had a lot of bad expirience with failing SD cards back in the days when the OS was there. So I strongly recommend you to leave only boot on SD and move whole OS on the USB drive, if it's applicable of coures. I guess depend on what is your use case. Some of my RPis are just for use when I travel so I leave all on SD card then.

Is there a simple way to force a device that's connecting with the usb-storage driver to reconnect using the uas driver?

Followed this guide and found that not all is cut and dry. I have a nvme enclosure that's marketed as UASP and USB 3.1 but when plugged into rPi4 it will switch the port to much slower 480MB. It is mounted as a boot volume, so I don't know whether this is down to the kernel not supporting faster speeds form a USB device. I tried plugging the drive to the other blue port. But with the same results.


The culprit has been identified. It's very much down to a cable. Make sure you use a true USB3.1 cable that's fully internally connected. I was using a USB-A to USB-C cable that I discovered was only USB2.0 compatible.

Anybody with a JMicron chip (JMS583) able to get their enclosure to run USB3 (5Gb/s speed)? Mine keeps switching to 480Mb/s. I've tested the unit on rPi4 as well as MacBook, trying different cables but all with the same result. So apart from a larger capacity, completely pointless upgrade.

/* Reported-by: Tom Arild Naess */
UNUSUAL_DEV(0x152d, 0x0539, 0x0000, 0x9999,

First, Jeff, this is the best post I've seen in a long time. Loved the video. Very informative. Now that I've buttered you up, I bought an ADATA SC680 specifically for Ubuntu Mate desktop. It came up as "Driver=uas" and I was tickled pink. However, tried to boot and it starts but fails ultimately with an 00000044 error. Tried quirks to no avail.

really interesting and well done article. I have to highlight, after tests, that if you use a USB3 hub probably also the hub has to support UAS.
Tried the same disk with same controller and I have got a UAS driver only if connected directly to the raspberry or the Mac, otherwise it doesn't use UAS driver.

Presumably you have a method that prevents a drive from using UASP when it normally would elect to do so since using the same storage device in a test of UASP vs plain BOT seems important.

I’d be interested to know how you told Linux to not provide (or disallow) UASP. I guess you could have just relied on the fact that one external case allows UASP and one does not but I think it would be 1) nice to be able to control it at the OS level and 2) the idea of using the same enclosure for all tests is attractive.

Nice write up!

a "safe" or "blessed" USB3-to-SSD/HDD adapter is the Startech USB3S2SAT3CB, amazon ASIN B00HJZJI84. Just giving the name so you can link with a affiliate code if you want and to cut down on it looking like I'm spamming :)

For the "hdparm -t" test, I see 40 mb/sec from SD cards and 260 mb/sec from my SSD with that cable- and a similar cable shows the same speed.

Be aware that the cable can't supply more than 900mA of current, because that's a USB3 limitation. Many users are writing negative reviews, seemingly because of this. Perhaps Raspberry Pi 4 can supply more? It might help to decouple the power from data by ripping off the cable and supplying 5V sideways, or making some Y passthru cable.

Anybody here tried RADXA 4 disk board with success?