____________________________________________ / Fool me once, shame on you. Fool me twice, \ \ prepare to die. (Klingon Proverb) / -------------------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || ||

(Excerpt from Ansible for DevOps, chapter 12.)

The fallout from this year's microSD card performance comparison has turned into quite a rabbit hole; first I found that new 'A1' and 'A2' classifications were supposed to offer better performance than the not-Application-Performance-class-rated cards I have been testing. Then I found that A2 rated cards offer no better performance for the Raspberry Pi—in fact they didn't even perform half as well as they were supposed to, for 4K random reads and writes, on any hardware I have in my possession.

And now, I've discovered that A1 class cards like the SanDisk Extreme Pro A1 actually perform better than A2 cards I've tested. And in a complete about-face from their A2 counterparts, it seems like A1 cards actually perform 2x better than their rated minimum spec:

The Extreme Pro A1 finally tops the random write performance of the three-year-old Samsung Evo+, though it's still a bit shy of the random read performance. What's more interesting to me (since I buy a ton of these little cards and cost is a major consideration) is the IOPS you get per US dollar:

So, unless SanDisk decides to halve their price points, the Samsung microSD cards seem to be the best value for any kind of 'application' level performance, even though it seems Samsung has not yet applied for any A1/A2 ratings on their cards yet. (Note: I couldn't find a 32GB version of the A2 SanDisk Extreme to purchase and test, so I'm sticking with the 64GB pricing.)

After posting the A2 card performance article, I received a lot of feedback in comments on Reddit and Hacker News, and one thing I learned is that to achieve the rated performance, it seems you need to have special firmware and/or kernel-level support for A2 Command Queue and Cache functions. From /u/farptr's comment summarizing the requirements:

Command Queue The new CQ mechanism allows the SD memory card to accept several commands in a series (without their associated data) and execute them (with the data) whenever the memory card is ready. It contributes mainly to random read performance. During the data transfer, additional commands may be sent to the card as long as the maximum number of queued commands does not exceed the maximum queue depth supported by the card (the SD standard allows queue depth of min 2, max 32). With CQ, advanced information on intended commands is provided to the card. The card may manage and optimize its internal operations to prepare for the various commands in advance. Multiple tasks can be handled at one time in arbitrary order. New information on next commands may be sent to the card during current execution and during data transfer. Cache function In order to overcome the relatively limited write speed operation of flash memory, the Cache function allows the card to accumulate the data accepted by the host in a high-speed memory (e.g., RAM or SLC flash)) first, release the busy line and perform the actual write to the non-volatile slower memory (e.g., TLC NAND Flash) in the background or upon flush command. The card may cache the host data during write and read operation. Cache size is card-implementation specific; flushing of contents stored in cache is done in less than one second. It is supported by OSs today for embedded memory devices and is assumed to be easy to implement for cards.

It seems like, for A1 cards, the card has to do all the hard work in its controller to achieve the IOPS benchmarks, whereas on A2 cards, a lot of the heavy lifting would be offloaded to the device or operating system. This has a couple interesting implications:

A2 cards, if they are ever properly supported by devices like the Raspberry Pi, may have different behavior in situations where the power supply is inadequate. For older microSD cards, a common problem is data corruption if you use a low quality power supply (and this has become a bigger problem every generation of Pi—you need a good power supply or you'll have a lot of annoying problems).

A2 cards seem to sacrifice some performance when used with hardware which doesn't have A2 Command Queue and Cache functions, versus A1 cards, which offer the same random I/O performance on any device.

So unless and until more devices and operating systems support A2 functionality, it's best to avoid purchasing any A2 cards. If you buy an A1 card, you'll get better performance now, and quite possibly forever. A2 might not technically be marketing BS, but in the real world, I stand by my assertion that it still is.

I haven't seen any indication there is work being done to add support in the Linux kernel, nor in the Raspberry Pi hardware, so I'd posit that, at least for most general computing purposes, the A1 and A2 designations from the SD Association are pretty meaningless, and you still have to rely on 3rd party testing to determine which cards give the best performance.