Update: See follow-up post about A1 vs A2 performance, Raspberry Pi microSD follow-up, SD Association fools me twice?.
After I published my 2019 Raspberry Pi microSD card performance comparison, I received a lot of feedback about newer 'A2' Application Performance class microSD cards, and how they could produce even better performance for a Raspberry Pi.
None of these cards are fakes; grainy halftone printing is visible because I shot this with a macro lens.
Until last year, it was hard to judge a microSD cards' suitability for the Pi without first purchasing and testing it, because the only marketed rating was for sequential read/write performance (e.g. 'U3' meant the card could write sequential files (e.g. large images or videos) at 30 MB/sec or higher, and 'C10' was for 10 MB/sec or higher). The Pi, as a general purpose computer, reads and writes very small files, and doesn't usually need faster large-file performance.
As more and more people use microSD cards for extra storage on their phones and tablets, or for system boot volumes on devices like the Raspberry Pi, there was a need for a performance metric more relevant to the random access patterns used in these scenarios.
Therefore the SD Association created 'Application Performance' class designations, A1 and A2. The minimum ratings are stated in this table:
This kind of performance metric is much more helpful for someone like me, so I was excited to purchase a few A2 cards and see how much more random I/O / IOPS I could get out of them. After all, 2000 IOPS for 4K random writes is approaching a low-end SSD's performance on an older SATA bus.
So I opened up an issue in the Raspberry Pi Dramble cluster's issue queue: Add three more microSD cards to the benchmarks, test A2 performance, and put two new A2 cards to the test (and one A1 card—it's results are in the linked issue):
I ran my usual microSD benchmarks (hdparm and dd to test sequential read/write speeds, then iozone to test random I/O), and what I found surprised me:
Not only were both cards underperforming the minimum required spec to meet A2 compliance—by more than half (4000 IOPS read, 2000 IOPS write)—they were also slower than some of my older microSD cards produced years before the 'A1' and 'A2' class designations.
I'm a skeptic, though, and I always like to challenge my own assumptions. So, before accusing manufacturers of inflating their card's performance claims, or the SD Association of rubber-stamping card performance designations, I wanted to see if there was any possible way for me to get the IOPS they were supposedly able to get.
Testing on two Macs
I used AmorphousDiskMark on macOS to test 4K random writes on both of the following Macs:
- MacBook Pro 13" 2015 i7
- MacBook Pro 13" 2016 i5 Function Keys
I also tested with four different readers: AUKEY USB-C hub with microSD reader, Rocketek XQD/SD card reader with two different SD card to microSD adapters (Samsung and Lexar), the built-in SD card reader on the 2015 MacBook Pro, and a UGreen UHS-II USB-C SD and microSD card reader.
The numbers were nearly identical in every test and device. I didn't put down all test results in the previously-linked GitHub test, but I was very thorough.
SD 6.0 Part I physical specification
So, thinking maybe I'm measuring something completely different (e.g. air compressor CFM ratings are complete BS), I read through the SD 6.0 Part I physical specification to see exactly how they benchmark these cards. I read every relevant portion, including the most important bit:
Note that unit of random performance [IOPS] indicate number of 4KB sized I/O Operations completed in one second, wherein each transaction was targeted to a random address generated for 256MB address range.
So it was definitely IOPS measured with 4KB random I/O, however the only tiny detail that was different was the address range; I use 100 MB for most of my tests, just to save time benchmarking many cards. I also tested with 512 MB and 1 GB ranges, and found the same performance numbers.
I fired up the Pi again, and ran the following iozone command to simulate the exact scenario listed in the SD 6.0 specification:
./iozone -e -I -a -s 256M -r 4k -i 0 -i 2
Nope. Same result, 9.58 MB/sec read, 2.55 MB/sec write. In fact, the speeds were so consistent (some microSD cards have a standard deviation in the 5-10% range!), maybe I've discovered the flaw in the SD Association's tests—instead of measuring success by IOPS, they're measuring success by low standard deviation! /s
I looked around the Internet to see if there were any other posts either supporting or contradicting my claims. I didn't find much, but one detailed post I did find seemed to conclude with the same results: The newest, fastest "app class" microSD cards are still not very good for apps. In their post, they said:
None of these cards were even able to hit A2 speeds in our tests. However SanDisk is calculating its IOPS (perhaps in super-short bursts, or with different IO request sizes?) it doesn't jibe with benchmarks.
I haven't found anyone performing real-world benchmarks proving any A2 cards reach the IOPS in the spec.
So A2 Application Class is marketing BS?
Yes.
If one of the microSD card manufacturers (in this case, SanDisk or Lexar), or the SD Association disagrees with my opinion, I'd invite them to show me any way to get the performance out of these cards that they claim they should be producing. I've tested with five different card interfaces, some over USB 3.1 and USB 3.0, on some very fast computers, with multiple disk benchmarking tools, and the results were consistently very poor.
All I can conclude is the microSD manufacturers are taking batches of their former 'not-A2-rated' cards and stamping an A2 on it, then doubling the price for the exact same card.
Conclusion: Don't buy A2 cards. Save half the money and buy the same card I've been recommending for years, the Samsung Evo+, which is not even 'A1' rated, but still beats any other card I've tested for price-to-value.
Comments
Over on Hacker News, megous posted a comment indicating that the features which enable faster I/O (Cache and Command Queuing) require Linux kernel support, which is not present yet. He linked to this article, which states:
Apparently, though, it will also need support added to macOS, Windows, Android OS, and everywhere else, too, because so far I've never seen an A2 card successfully meet any of the performance benchmarks touted in the spec on any kind of hardware. So my conclusion is still correct, until maybe someday in the future, when some magical new software / firmware support is added everywhere. Until then, you're paying for something you can't use. Save the money and buy A1 or non-Application Performance class rated cards.
I found only one test where an A2 card achieved true A2 IOPS figures: https://www.techradar.com/reviews/micron-1tb-c200-microsd-uhs-i-card
Maybe someone should check the kernel sources for the Ulefone Power 5S which they used for testing.
Their report makes no sense to me:
If they were testing sequential read/write, were they testing with 4K blocks? Did they do any random I/O test? I can't even come up with a block size that would result in the translation of 80 MB/s to 4466 IOPS. Maybe they're mixing up internal storage results for IOPS with the sequential results for MB/s from the card?
That reads to me as a slightly clumsy reporting of two different tests - "hit sequential read/write speeds of 81/75MBps and [in a separate random I/O test] 4466/2284 IOPS"
Good catch
Thank you for your post and the many others you've produced on SD performance.
I've also found the Samsung Evo+ cards to be insanely reliable: I have in excess of 30 of them and I haven't had any failures to date, vs multiple SanDisk read-only failures. They're also both speedy and reasonably priced.
On an RPi 3B+, the MicroSD interface will only take advantage of the U3 card's faster speed, V30-60-90 makes no difference. On RPi 4B I have not tested the faster cards yet to determine if the MicroSD interface will support the faster performance cards.
My current results on a Windows box can be viewed @ URL: https://kraziemonkie.com/Docs/Reply.png
Note that those are _sequential_ read/write figures. As the article correctly states, what matters for a Pi boot card is _random_ performance.
is there any clue that we can optimize the performance of the sd/emmc driver? i have read the soure code and want to dig a little more about the bsd mmc/sd drviers.
is there any difference compare with Linux BIO?
i also found that the SDHCI are not using the ADMA2 instead of SDMA which is known to be faster.
Great article, I am not into the Raspberry tech at all, but went down this SD card rabbit hole a couple years ago, when I was starting my Drone photography business, A1 class was just on the horizon, and I couldn't believe how many markings there were on an SD card. Didn't do the testing like you. but found some good articles, some spec sheets along with tech and a back story to why. Apparently the SD Card Association isn't known for the best decisions. You probably know most of this, but the C(class) rating was first, then U rating then V or Video class. They all represent exact same thing, minimum read/right speed, the card will preform at. Each classification being released as technology surpassed their rating system. Problem was, they didn't do this with much fanfare, and usually when people were just getting used to the last system. So some manufacturers to this day, still put all three ratings on their cards, So if you have "C"w/ 10 in the middle, a "U" w/ 1 in it, and V10, the card writes at 10MBps. Manufacturers also, unfortunately, will put all three, using the highest the first two rating systems go, along with a V60 SD card for example. So you could have a card with C10. U3 and V60 on it.
I was also wondering have you ever ran similar tests on SD cards pre A1 classifications? The attached article states that the SD Card Association only requires one of the other, read or write, and obviously manufacturers are going to put the read speed, as it's most often faster. I know though, most people, at least non tech folks, refer to that as the write speed. I have seen a few test studies online, a couple back up the below article, one does not. Was just curious if you have further better knowledge of that rating vs real world speed. Thanks again for a great review and article!
Oh yeah, from the drone photog world, I agree with many of commenters, even though not as popular in traditional photography, the Samsung Evo is the go to in drone photography, good prices, for a solid work horse of a SD card, that often can take a beating depending on the pilots skill and willingness to get a tough shot.
https://shuttermuse.com/understanding-sd-card-naming-speeds-symbols/
You are mostly right but V10, U1, and C10 do not say the exact same thing. In theory, a V30 card is not necessarily U3, and a U1 card is not necessarily C10. This is because the test conditions are not the same in each class rating scale.
For example, U1 requires the UHS mode but not C10. A card could reach 10 MB/sec in UHS mode but not in legacy mode. Similarly, V30 requires a more recent protocol (or command set) than U3. A card could reach 30 MB/sec in a recent "V-ready" device but not in an older device (which requires a U3 card).
My Transcend 300S class 'a1' 256GB microsd gets me 6385kB/s random read and 2856kB/s write at 4k packets
with ./iozone -e -I -a -s 100M -r 4k -i 0 -i 1 -i 2
sequential 4k r/w is identical to write on this card. My sandisks and samsungs are close, but not as fast.
I think transcend does a better job with their controllers
I will try Samsung Evo+. I'm currently using a Kingston MicroSD card from Buykingston.co.uk, and it's working pretty well. I didn't face any issue yet. Anyway, your post has good points and I would like to bookmark it.
It would seem that Class A2 requires a SD 6.0 spec card reader and support for the UHS-III interface bus that increases potential read/write bandwidth up to 624 MB/s (double that of the UHS-II).
UHS-III uses the same second row of SD card pins that are also present on the UHS-II cards causing the above confusion.
https://www.sdcard.org/developers/sd-standard-overview/application-perf…
https://www.anandtech.com/show/11171/sd-association-uhs-iii-a2-class-lv…
I leave it to you to figure out what the card readers and USB of the various RPIs can handle, but USB 3 wont handle UHS-III speeds.
https://www.raspberrypi.org/forums/viewtopic.php?t=243615