A2-class microSD cards offer no better performance for the Raspberry Pi

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.

A2 Performance Class SanDisk and Lexar microSD cards next to older Samsung and SanDisk cards
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:

microSD A1 and A2 Application performance class standards

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:

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:

A2 Application Performance class microSD cards compared to older non-A1 cards

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:

A2 cards can only show their performance if the host is also 'A2 compliant' needing updated MMC drivers to deal with these new cards. It seems at the time of this writing this is still missing in Linux (tested with 4.19.0-rc4).

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:

When it comes to Android performance, we used the Ulefone Power 5S and AndroBench. The drive hit sequential read/write speeds of 81/75MBps and 4466/2284 IOPS (read/write in both cases).

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"

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.