> 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
Wow, holy shit, TIL.. I was always assuming that USB drives were always SCSI — they show up as 'da' (Direct Attach) on FreeBSD after all.
Looking at umass driver source:
* The driver handles 3 Wire Protocols
* - Command/Bulk/Interrupt (CBI)
* - Command/Bulk/Interrupt with Command Completion Interrupt (CBI with CCI)
* - Mass Storage Bulk-Only (BBB) (BBB refers Bulk/Bulk/Bulk for Command/Data/Status phases)
* Over these wire protocols it handles the following command protocols
* - SCSI
* - UFI (floppy command set)
* - 8070i (ATAPI)
* UFI and 8070i (ATAPI) are transformed versions of the SCSI command set.
Huh, they are pretty much always SCSI, and "bulk only" is (unsurprisingly) only a USB transport level thing that doesn't change the command set.
I guess "UASP" is some sort of marketing term for Command/Bulk/Interrupt then..?
It isn't just a matter of speed. There are some drive commands that only work when you attach a device via an adapter that supports UASP. OPAL drive encryption being one.
> The native Intel USB3 UASP solution is only supported under Windows 8. To further complicate matters, not all Z77 motherboards support USB3 UASP. A license is required to implement UASP, and not all motherboard manufacturers are prepared to pass on the extra cost of this license to the end user
Sounds very cursed. I mean, I'm not a hardware vendor, I should not care, but licensing for something that's just another form of SCSI over USB sounds ridiculous.
I didn't know they even supported scsi, I knew about the old BOT-protocol and the huge limitations for harddrives over USB, and for that reason I've always avoided them whenever possible with the assumption that the basic limitations of the protocol was still true for 3.0 drives.
This does put USB-drive in a better light for me. I might event buy UASP supported USB 3.1g2/3.2 SATA-controller and do some testing myself.
I usually try to reach for a bus-connected controller which usually mean thunderbolt today for external enclosures (expensive), but it would be nice to build a portable DAS-array that can be connected to any device with USB-C.
> 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.
No no, even better! Peak power consumption is lower, but the same work is completed much more quickly due to increased throughput, so the energy required for the same work is decreased dramatically. Between the performance increase and the lower power usage I wouldn't be surprised if this reduces energy use by 50 %.
Yeah. This kind of savings comes up in interesting places elsewhere -- if you make your algorithm run twice as fast but using twice the memory, your time-integrated memory use (measured in gigabyte seconds) remains the same. So if you can make good use of that memory while your algorithm isn't running, you're saving CPU and not really using more RAM.
For something like the Pi this is unlikely, but in data centers with big, latency-insensitive distributed workloads "using memory for less time" can be a real win. (The battery example with the Pi really is the perfect example though, because you're usually interested in the time-integrated value more than the peak draw.)
It depends a lot on the workload, though. That kind of statistic is hard to draw any solid conclusions from, except that “it uses less CPU and less overall power during IO activity” and you’ll save some amount of energy consumption (depending on what you’re doing).
The Pi 4 is a big revolution, fast enough to serve as a desktop computer for most office people, students, and so on. It's pretty impressive and more attention is being paid to it as a first-class computing platform as time goes on.
Our desktop monoculture has led to serious security problems and massive stagnation at least until recently. Even if you don't use a Pi you should be thankful that they exist.
It should be and is decent, but when we tried we ran into numerous paper-cuts:
- Needed to set up NTP to set the clock, it was always wrong.
- It can't power down through software, so you have to shut down and then hit the power switch like it's 1990.
- Audio was a mess and had to spend hours researching how to write and edit a bunch of config files to make it predictable.
- The weird set up program means you need to do a lot of googling on how to fix issues in a non-standard to linux way. It mostly works however.
- Raspbian feels not quite "finished." Was much happier with Ubuntu Mate, as they fixed 99% of the paper cuts like audio already, but it doesn't support the 4 yet.
In short, it is a bit too cheap. I would have definitely spent another dollar to see these hardware issues fixed. Or dropped the CPU speed a hundred MHZ, whatever it takes.
In the end, a friend gave us a ten-year-old used iMac for free. I installed Ubuntu Mate on it and it had none of the above problems. It's even a touch faster.
A touch faster? The slowest 2010 iMac is the 21" with an i3-540 Dual core CPU, Geekbench 4 is 2211 single/4466 multi. The Pi 4 is around 970/2000, less than half the performance.
The Pi 4 has come a long way in speed since the lowly original Pi, but its still not even close to a 10 year old desktop PC (or iMac).
Just run Windows 10 for the Pi and call it a day. Linux for desktop is still a disaster and no surprise Windows 10 for the Pi actually works out of the box.
The CPU is now (IMHO) the major sticking point for many of my own use cases. It would also be nice to have an easier / less cumbersome way to connect higher speed storage. (The mess of cabling you get with an add-on USB 3.0 drive is annoying.)
I also had a recent install that was unbearably slow. It turns out that the SD card was corrupted. Raspberry Pi OS comes with a SD card checking utility you can use to check. Replacing it with a new class 10 card made it fast again.
For my money they've pushed a fraction too hard on the CPU power. One of the best things for me about the 3 is that you don't need to worry about cooling the way you do with the 4. I get why, there's a huge demand for the 4 to be able to handle proper desktop applications, but I'd love to see a version that has the thermal characteristics of the 3 with the IO updates of the 4.
I'd actually like a new version of the Compute Module with the PCI-e lanes exposed (the more the better). That would be a real game changer for NAS systems.
Or, for both CM and the full RPi, a docking header and a corresponding tiny module for a real-time clock module if not outright embed one. It's 2020 ffs.
The Cortex-A53 is really weak. I wouldn't want to run an office suite on that either. Oh, and the Pi 3 was VERY limited by RAM.
"most office people, students, and so on" pretty much always do browse lots of modern websites, at the same time as running an office suite, audio player, and more stuff.
The A72 is really the "minimum viable CPU core" for desktop usage. Anything with less single-core performance is absolute hell and suffering.
Then I disabled UAS. Haven't had any corruption since. It's not absolute proof, but I believe the firmware and/or driver support for UAS with this dock is buggy, and the older protocol works fine. I like speed as much as the next person, but not if it means repeated filesystem corruption...
I'm all for blaming dodgy chipsets, but the Superspeed and Superspeed+ support in Linux definitely has not had all of its rough edges filed off yet either--especially the stuff that uses streams and asynchrony.
However, the article comparing to USB 1.1 is silly.
If you are on USB 2.0 (and I haven't bumped into anything mass storage in the last 10 years that isn't), the bulk endpoints are quite happy to take advantage of the USB 2.0 bulk packet size (512 bytes) and microframes (120us turnarounds) with 13 packets per microframe.
That's going to get you in the 400Mbps+(40Megabytes/sec) range without a lot of problem.
That’s still less than half the speed you get from USB 3.0 even without UASP from a cheap SSD. I drew the 1.1 comparison mostly to illustrate the fact that the general protocol for MSD on USB was created in the late 90s for an interface 400x slower than 3.0.
Not really, even the fast microSD cards have ~1000 IOPS. Regular A1 cards have 500 random address write IOPS. Most USB attached SSDs will top that many times over. It's not really hard to top 2-4 MiB/s write speeds by an order of magnitude.
This is more up-to-date, and includes more models of Pi’s and SD cards. It was linked in your post, but the post is now out-of-date relative to my link below.
If you want to bookmark a page, that's the one that I update every year or two (usually after a new Pi model is released). The blog posts fade a little in relevance over time since I don't keep them updated.
Excellent reading this; My Pi4/8GB cluster uses a 1000bT PoE hub for a backplane, and / is an nfsroot from a node running a Sandisk UASP USB3 SSD. Like the author, I'm blown away by the fun to be had with Docker and Kubernetes on this cluster. Unlike the author, I'm having a great experience with it as a Mac-replacing daily driver (thanks mostly to never running chromium on the same node that runs gnome-session, to spread things out a bit). Love to read about everyone's Pi cluster adventures.
I think I could make it work, but the hindrance to my media (library of 65,000+ RAW photos from three different camera bodies and about 8 TB of 1080p video projects (and counting)) workflows was what really killed it for me.
Even basic photo import / adjustments were a pain with any of the applications I tested, and that was partly due to the Pi's slower GPU/CPU, the 64-bit ARM paucity of desktop apps, and the lack of good (read: like Adobe/Apple/pro-tier media apps) UI-based applications on Linux.
Most of the other issues (like window management and resolution problems) I ran into with the 'Pi for a Day' project I could probably resolve with a few more days' work.
I'm going to be testing a few different thumb drives in my next post / video. I have a couple SanDisk models and an Arcanite USB 3.1 drive that I'll be testing... but I don't believe they use UASP (haven't had time to confirm that suspicion yet).
Thanks Jeff, you’re doing a great service to the community here. I’ve tried to hunt around for a good system drive and fell short so far; support for UASP/TRIM in thumb drives is both rare, and seldom specified by manufacturers even when present. Looks like the only way is to buy a bunch and try.
I am not sure about which pen drives support UASP, but one thing of note is they recently updated their firmware (June 15th) to support boot over USB instead of the SD Card. I have mine setup this way now, using an external hard drive enclosure that supports UASP. Works great.
Almost all USB thumb drives are garbage for booting OS because very bad performance for random read/write (Getting worse over time). IIRC SanDisk Extreme Pro is an exception.
I've been using UASP SSD drives in Linux for ~ 5 years, the main issue I face is not performance related but w.r.t monitoring.
S.M.A.R.T doesn't behave well with UASP, so not all Smartmontools's feature work[1]. Especially, LifeTime of the SSD don't and they are crucial. I had to resort to calculating remaining life of the SSD manually from the reported lifecycles and negating it with the manufacture's MTBF if they're reported.
I've faced this with devices from varying price range [USB 3.0/3.1] - MyDigitalSSD(OTG), Samsung T5, various ORICO USB SSD enclosures with Samsung EVO/Crucial SSDs on host systems of different architectures(x86/ARM).
How are you all monitoring the life of your USB SSD on UASP in Linux?
smartctl 6.6 on Ubuntu18.04 Jetson Nano (aarch64) gives Total_LBAs_Written for Samsung 840 Evo in ORICO USB 3.0 SSD enclosure (UASP) and Samsung T5 SSD USB 3.0 but failed to read S.M.A.R.T data properly for MyDigitalSSD(OTG) which is likely the fault of the controller in it.
So with Total_LBAs_Written we can find TBW (Total Bytes Written) and compare it with manufacturer's data[1].
Readit News
Wow, holy shit, TIL.. I was always assuming that USB drives were always SCSI — they show up as 'da' (Direct Attach) on FreeBSD after all.
Looking at umass driver source:
* The driver handles 3 Wire Protocols
* - Command/Bulk/Interrupt (CBI)
* - Command/Bulk/Interrupt with Command Completion Interrupt (CBI with CCI)
* - Mass Storage Bulk-Only (BBB) (BBB refers Bulk/Bulk/Bulk for Command/Data/Status phases)
* Over these wire protocols it handles the following command protocols
* - SCSI
* - UFI (floppy command set)
* - 8070i (ATAPI)
* UFI and 8070i (ATAPI) are transformed versions of the SCSI command set.
Huh, they are pretty much always SCSI, and "bulk only" is (unsurprisingly) only a USB transport level thing that doesn't change the command set.
I guess "UASP" is some sort of marketing term for Command/Bulk/Interrupt then..?
https://en.wikipedia.org/wiki/USB_Attached_SCSI
Sounds very cursed. I mean, I'm not a hardware vendor, I should not care, but licensing for something that's just another form of SCSI over USB sounds ridiculous.
This does put USB-drive in a better light for me. I might event buy UASP supported USB 3.1g2/3.2 SATA-controller and do some testing myself.
I usually try to reach for a bus-connected controller which usually mean thunderbolt today for external enclosures (expensive), but it would be nice to build a portable DAS-array that can be connected to any device with USB-C.
No no, even better! Peak power consumption is lower, but the same work is completed much more quickly due to increased throughput, so the energy required for the same work is decreased dramatically. Between the performance increase and the lower power usage I wouldn't be surprised if this reduces energy use by 50 %.
For something like the Pi this is unlikely, but in data centers with big, latency-insensitive distributed workloads "using memory for less time" can be a real win. (The battery example with the Pi really is the perfect example though, because you're usually interested in the time-integrated value more than the peak draw.)
Our desktop monoculture has led to serious security problems and massive stagnation at least until recently. Even if you don't use a Pi you should be thankful that they exist.
- Needed to set up NTP to set the clock, it was always wrong.
- It can't power down through software, so you have to shut down and then hit the power switch like it's 1990.
- Audio was a mess and had to spend hours researching how to write and edit a bunch of config files to make it predictable.
- The weird set up program means you need to do a lot of googling on how to fix issues in a non-standard to linux way. It mostly works however.
- Raspbian feels not quite "finished." Was much happier with Ubuntu Mate, as they fixed 99% of the paper cuts like audio already, but it doesn't support the 4 yet.
In short, it is a bit too cheap. I would have definitely spent another dollar to see these hardware issues fixed. Or dropped the CPU speed a hundred MHZ, whatever it takes.
In the end, a friend gave us a ten-year-old used iMac for free. I installed Ubuntu Mate on it and it had none of the above problems. It's even a touch faster.
The Pi 4 has come a long way in speed since the lowly original Pi, but its still not even close to a 10 year old desktop PC (or iMac).
https://psref.lenovo.com/syspool/Sys/PDF/ThinkCentre/ThinkCe...
I’m surprised there’s no Raspberry Pi case with a slot for a 2.5” drive and integrated USB 3.0 SATA controller.
been using it for photo sync only, works fine enough as long as youre not using the web interface
Or, for both CM and the full RPi, a docking header and a corresponding tiny module for a real-time clock module if not outright embed one. It's 2020 ffs.
Deleted Comment
Even the Pi 3 was already good enough for most of those use cases. The main exception being browsing modern bloated websites.
So, the most common use case for a desktop computer?
"most office people, students, and so on" pretty much always do browse lots of modern websites, at the same time as running an office suite, audio player, and more stuff.
The A72 is really the "minimum viable CPU core" for desktop usage. Anything with less single-core performance is absolute hell and suffering.
I have a cheap Inateck dock which does support UASP (the FD2005). Two or three times I had a bunch of errors like these:
followed by filesystem corruption.I found other folks complaining about similar problems, eg: https://unix.stackexchange.com/questions/239782/connection-p...
Then I disabled UAS. Haven't had any corruption since. It's not absolute proof, but I believe the firmware and/or driver support for UAS with this dock is buggy, and the older protocol works fine. I like speed as much as the next person, but not if it means repeated filesystem corruption...
However, the article comparing to USB 1.1 is silly.
If you are on USB 2.0 (and I haven't bumped into anything mass storage in the last 10 years that isn't), the bulk endpoints are quite happy to take advantage of the USB 2.0 bulk packet size (512 bytes) and microframes (120us turnarounds) with 13 packets per microframe.
That's going to get you in the 400Mbps+(40Megabytes/sec) range without a lot of problem.
In UAS mode it would work for a couple of seconds and start to fail, dropping transfer speed to a couple of hundred kB/s
I looked it up because i know enough about hardware that this shouldn't be the case (even with a cheap SD Card). Seems it's a limitation of the Pi's SD Card slot. https://www.jeffgeerling.com/blog/2018/raspberry-pi-microsd-...
https://pidramble.com/wiki/benchmarks/microsd-cards
Even basic photo import / adjustments were a pain with any of the applications I tested, and that was partly due to the Pi's slower GPU/CPU, the 64-bit ARM paucity of desktop apps, and the lack of good (read: like Adobe/Apple/pro-tier media apps) UI-based applications on Linux.
Most of the other issues (like window management and resolution problems) I ran into with the 'Pi for a Day' project I could probably resolve with a few more days' work.
Is it possible to run a Pi 4 using UASP if I set it up to boot from a decent (Sandisk/Samsung/etc) USB 3.1 pen drive?
Also, is this a reliable setup, or will the device be more stable if booted and run from a MicroSD?
Deleted Comment
S.M.A.R.T doesn't behave well with UASP, so not all Smartmontools's feature work[1]. Especially, LifeTime of the SSD don't and they are crucial. I had to resort to calculating remaining life of the SSD manually from the reported lifecycles and negating it with the manufacture's MTBF if they're reported.
I've faced this with devices from varying price range [USB 3.0/3.1] - MyDigitalSSD(OTG), Samsung T5, various ORICO USB SSD enclosures with Samsung EVO/Crucial SSDs on host systems of different architectures(x86/ARM).
How are you all monitoring the life of your USB SSD on UASP in Linux?
[1]https://www.smartmontools.org/wiki/USB
smartctl -a -d sat /dev/sda
Newer versions of smartmontools shouldn't need it, only the older one that Raspberry PI OS has.
smartctl 6.6 on Ubuntu18.04 Jetson Nano (aarch64) gives Total_LBAs_Written for Samsung 840 Evo in ORICO USB 3.0 SSD enclosure (UASP) and Samsung T5 SSD USB 3.0 but failed to read S.M.A.R.T data properly for MyDigitalSSD(OTG) which is likely the fault of the controller in it.
So with Total_LBAs_Written we can find TBW (Total Bytes Written) and compare it with manufacturer's data[1].
[1]https://www.virten.net/2016/12/ssd-total-bytes-written-calcu...