You can view a video related to this blog post here: Does UASP make the Raspberry Pi faster?.
A couple weeks ago, I did some testing with my Raspberry Pi 4 and external USB SSD drives. I found a USB 3.0 SSD was ten times faster than the fastest microSD card I tested.
In the comments on the video associated with that post, Brad Manske mentioned something I never even thought about. He noticed that I had linked to an Inateck USB 3.0 SATA case that didn't have UASP.
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.
And when it did arrive, I tried to see what was different about it. The top, sides, and back are completely identical.
On the bottom, the only difference is one additional letter in the model number.
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 /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
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.
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.
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.
What's the chipset of the UASP one?
The one on the bottom right (supporting UASP) is an ASMedia ASM1153E.
The one on the top left (not supporting UASP) is a NOREL Systems NS1066X.
I have a USB-SATA enclosure with ASM chipset (not sure which one 1051E 1053E 1153 or 1153E) that has UASP driver support.
Running in Pi 4B - but over time (a few hours ) it has errors (seen in dmesg log) and un-mounts.
I have to run a Cron job at 5 minute intervals to check that the drive stays mounted. Otherwise it will randomly unmount and stop working. Using with a 1 TB Samsung EVO SSD. connected to Pi4B via a powered 3.0 USB hub.
dd benchmark tests: 226MB/s write of /dev/zero to drive, 11 MB/s (with errors) for file copy on SSD, 14 MB/s read to /dev/null (with errors in dmesg).
hdparms -tT result: Cached read: 720 MB/s Buffer Disk Read 287 MB/s
Added "quirk" to the /boot/cmdline.txt file to revert to usb-storage BOT driver. dd write performance dropped a bit but the copy and read performance increased by 9X. And drive stays mounted over time.
This is because your device/bridge claims that it has UASP support, but it seems that your USB-SATA-bridge chipset does not properly pass SAT commands on to the SATA device when running in UAS mode. Enabling the NO_ATA_1X kernel flag reverts back to usb-storage for this device and restores stable communication.
Good description can be found in the smartmontools page (SAT-with-UAS-Linux) incl. a list of supported/unsupported devices.
Super interesting, thanks for sharing. A while back I set my RPi4 up to boot via USB using James A. Chambers' guide
(https://jamesachambers.com/raspberry-pi-4-usb-boot-config-guide-for-ssd…) 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 https://github.com/raspberrypi/linux/blob/rpi-5.7.y/drivers/usb/storage… .
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"
So if my Vendor is 0x2109 and the product is 0x0715 am I ok? The code shows an entry for 0x2109 but 0x0711/711 as the UNUSUAL_DEV. It looks like a revision update... hopefully patched up.
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.)
Minor quibble about: "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.
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.
You have any blog posts that provides details of your timelapse photo setup?
Yep! In 2017 I posted this, and I still use that rig quite often. It uses this GitHub project, which I still use and maintain.
It works with the Pi Camera Module and the High Quality Camera; I have a series of videos on YouTube that use the Pi time-lapse rig too: https://www.youtube.com/watch?v=lkKZ8Ww50fc&list=PL2_OBreMn7Fpviykd5nnuEjrymmF8fDc7
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.
True, depending on your workload and how read/write heavy it is.
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: https://www.aliexpress.com/item/32818860458.html 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:
Bus 002 Device 003: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
|__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
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.
Good info - my Samsung QVO 1TB drive does not support FUA. Hence it won't support UASP ??
[55287.666914] scsi host0: uas
[55287.668099] scsi 0:0:0:0: Direct-Access Samsung SSD 870 QVO 1TB 0 PQ: 0 ANSI: 6
[55287.669054] sd 0:0:0:0: Attached scsi generic sg0 type 0
[55287.670116] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
[55287.670287] sd 0:0:0:0: [sda] Write Protect is off
[55287.670303] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
[55287.670600] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
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
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 https://www.pbtech.co.nz/product/ADPUNI1045/Unitek-S1201A-USB31-Gen2-Type-C-to-M2-SSD-PCIeNVMe 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.
I'm struggling to run Realtek RTL9210 chipset (NVMe to USB), the topic here https://github.com/raspberrypi/linux/issues/4130
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,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
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.
You should go to the latest Pi 4 usb boot beta thread and discuss the issue there (also search in that thread if anyone else is hitting this same problem).
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!
This forum post over on the Raspberry Pi forums will be of interest. You can disable UASP on a per device model by adjusting the cmdline.txt file on the Raspberry Pi: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=245931&sid=6ae1…
I have had to force my USB <> SATA enclosure down to BOT as the JMicron chip in it seems unstable with the Raspberry Pi...
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?
Sadly I can't endorse UASP, my Jmicron based startech 4 disk enclosure always resets and corrupts my raid 5, only way to be safe is to add quirk to switch it off
I was able to get almost 400MB/s running hdparm with RAID0 on 2 UASP attached SSDs, unfortunately the pi would drop both USB devices as soon as I tried to actually copy any data to the RAID. Switching to Y cables on the drives for extra power didn't help either.
I've had success upgrading firmware on a couple JMS567 cables. 1 wouldn't usb boot prior to upgrade of OEM firmware and both now reliable with UASP and TRIM enabled. I upgraded to v173.01.00.02 from "https://wiki.odroid.com/odroid-xu4/software/jms578_fw_update".
Bus 002 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
I am late to the game, I know, but I just wanted to drop in a big "thanks" for this information. My data speed improvement on my pi4 is right in line with what is seen here. I used the Sabrent EC-SS31 adapter on Amazon. Now off to build a case out of Lego as with my Pi W Zero. :)
Lego case for the win!
Great article. But how do you enable UASP?
Hoping you could help with a situation. I have a Raspi4b that I have been trying to boot from USB on the USB3 ports. It boots OK using a 128 gb flash drive. But when I try to use an external SSD on the USB 3 port the system just hangs. If I move to the USB2 ports boots just fine. The SSD is a 128gb mushkin Raw drive (cheap & slow) encased in an ORICO interface which has UASP capability. (this is exact case -> https://www.newegg.com/orico-2139u3-bk-enclosure/p/0VN-0003-000Z5?Item=… ) Appreciate any thoughts / help
I tested multiple cables, here is my results of testing different cables:
Inateck SATA to USB Adapter Cable with UASP (NOT WORKING):
Inateck USB 3.0 to SATA 2 Cable USB 3.0 to SATA Adapter for 2.5 Hard Drive HDD SSD (NOT WORKING)
N USB 3.0 to SATA Adapter Converter for 2.5 Inch Hard Drives SSD/HDD, 20 cm, Supports UASP (NOT WORKING)
CSL – USB 3.0 to SATA Converter Adapter for 2.5/3.5 inch SATA HDD/SSD Drive | USB Attached SCSI Protocol (UASP) SATA 3/6G Hot Swap (WORKING)
Got another one for the naughty list. I got it because I really liked the 6 inch cable, but doesn't appear to be UASP (can't confirm with lsusb since I'm on Alpine (HassOS), but hdparm results were disappointing)
CableCreation USB 3.0 to SATA Adapter, SATA to USB 3.0 Cable, Compatible 2.5" SATA III HDD Hard Disk Driver, 0.5FT, Black - https://www.amazon.com/gp/product/B01ESJS36Q/
Hello,i want too use a normal 2.5 hdd in Rpi4
I have the official Rpi4 psu,i get random errors in Raapian OS if i connect also a flash drive with the hdd connected,is there a command that i can put in config.txt to fix this problem?
My experience; The cases with JMicron controller can't sync correctly with the pi. The cases with Asmedia work ok. I got 380 MB/s with those. Both have uasp by default but JMicron is incompatible. And only the lower USB3 port is 5000 Gbit/s capable. All other both USB 2.0 and 3.0 port's of the RPI4 are 480 Mbit/s only capable.
I'm plugged into the upper USB3.0 port and showing 5000M