(Comments from Blogger)
2019-12-16 by anderp h
The UAS issue is because it’s a JMicron USB-to-SATA bridge and they don’t properly pass all ATA commands - have a look through some of the smartmontools doco around the ‘usbjmicron’ module and passing SMART commands through. Some info here: kernel - Connection problem with USB3 external storage on Linux (UAS driver problem) - Unix & Linux Stack Exchange and here: USB/UAS - linux-sunxi.org
The issue is firmware-dependent; most devices will work just fine if you force-enable UAS, some refuse to work like yours - some of my Seagate 5TB drives in one color work fine, some don’t work at all - slightly different firmware revisions, but same ven/devID. It’s a bit of a nightmare.
2019-12-16 by Russell Graves
Thanks - that’s some useful background! I suppose I should try a few different enclosures and see how performance differs on them with/without UAS.
2020-02-06 by Cpt Hooke
Have you seen this article https://medium.com/@matteocroce/why-you-should-run-a-64-bit-os-on-your-raspberry-pi4-bd5290d48947 on the benchmark difference between 32bit and 64bit Debian when running on the Pi4? The results aren’t surprising, but it’s good to have some data to reflect this.
2020-02-06 by Russell Graves
I’ve seen it. If your workload is running the Dhrystones benchmark all day long, absolutely, build a 64-bit version.
What that set of benchmarks misses, IMO, is that 64-bit binaries generally have a larger memory footprint because of the increased pointer size - and on a RAM limited device, that can really hurt things as well. ARMv8 in aarch64 mode is definitely nicer to work with, and has better performance, /in some cases/. But to run a few benchmarks and then assert blindly that the system should be 64-bit… that’s not how you do full system benchmarking/analysis.
It’s on my list of things to poke with, just fairly far down.