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.

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):

• SanDisk Extreme 64GB U3 V30 A2
• Lexar Professional U3 A2 V30 128GB
• Samsung Pro Endurance 32GB U1

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.