Users of development boards booting from (micro) SD cards have often missed random I/O performance information to determine whether the device would performance well to run an operating system, but now that Google has implemented “adoptable storage” to let consumer run app from their micro SD cards, it has become an important differentiating factor for manufacturers, and the SD association announced A1 App performance class with minimum random I/O read/write performance and at least 10MB/s sequential write speed last year. The SD association has now unveiled Class A2 with better I/O performance with minimum requirements of 4000 IOPS for random reads, and 2000 IOPS for random writes, with the same 10 MB/s minimum sequential write speed.
That means the application performance table now looks as shown below. Note that Class A2 is not available right now, and test requirements will be explained in SD 6.1 part 1 physical specification to be released later this year.
Compliant (micro) SD cards will be easy to spot with A1 or A2 logo on the card and package. The SD association came to those numbers in collaboration with Google. The main advantage of such cards will be that the app will load faster, and you’ll get less occurrences of “app is not responding” window in Android due to slow I/Os.
Beside performance requirements, Class A2 also brings some new compulsory features:
- Command Queue
- Contributes mainly to random read performance
- Multiple tasks can be handled at one time with arbitrary order
- New tasks can be assigned during data transmission
- Cache function
- Contributes mainly to random write performance
- Card may use higher speed volatile memory to cache the host data during memory card access operation
- Self-Maintenance
- Contributes to better memory access performance
- Allows internal background data management
- May be initiated either by card or by the host based on the card’s internal needs
SD Specification 6.0 also introduces the Low Voltage Signaling (LVS) memory card that may support either 3.3V or 1.8V signaling with an auto detection mechanism of the host’s operating signaling level. The new specification allows LVS cards to be backwards compatible to conventional 3.3V signaling hosts. Both Class A2 and LV were announced in the same press release.
SD Cards are still being to store large files such as photos and videos, so sequential performance is still important, and that’s why the SD association also announced UHS-III delivering up to 624 MB/second for applications such as 4K/8K video recording and high resolution 360° videos.
UHS-III is defined in SD specification 6.0. We can notice some extra pins for UHS-II and UHS-III cards in the diagram above, so the host system will have to support this extra bus to benefit from the extra performance.
Charbax interviewed the SD association at Mobile World Congress 2017 where they talked about both announcements.
More details can be found in the SD association’s Application Performance Class and Bus Speed pages. You may be interested in a white paper entitled “Mobile Device Innovations: Application Performance Class Expansion and New Low Voltage Signaling for SD Memory Cards” to find out more.
Thanks to Theguyuk for the tip.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Thats pretty great to see focus on random performance. Great for SBCs !
Can anybody explain the difference between IOPS and MB/s?
Can a card have 10MB/s and a very low IOPS rate and another card with also 10MB/s has a very high IOPS rate?
@Martin
IOPS is Input Output per second and in the hard drive world would be the equivalent of “seek time”, while the MB/s is the sequential data rate.
If you record a video, the system will open a large file, and write data sequentially to it. For that you need a high bitrate, so some data will be lost during recording. That’s the MB/s number you get with Class 10, UHS-I, etc…
When you run apps and an operating system, the workload is different. You don’t have a file with a large amount of data, but instead many small read and write operations. If we think about mechanical hard drive, the head waste a lot of time seeking small files or databases are spread around the drive. IOPS are a little like that. If you’ve ever upgrade a computer from a mechanical hard drive to an SSD, you’ll have seen a big difference when it comes to boot time, and program startup times. An analogy could be that SD card with low IOPS are like an (old) hard drive, while Class A1/A2 SD card will feel more like an SSD.
Are there uhs-II and uhs-III cards also more durable?, and are they backwards compatible so they work on older boards?
Yep and that’s still a huge problem. You can get SD cards showing pretty decent sequential performance that totally suck with random IO. If you use the card in a camera then sequential throughput is all that’s important (and that’s SD Association’s so called ‘speed class’) but that’s totally different if we’re talking about embedded devices and especially Android or a ‘Desktop Linux’.
When we (Armbian users) tested a lot of SD cards and onboard storage we realized that there are SD cards out there that are labeled ‘class 10’ and fulfill these requirements but perform absolutely different when it’s about random IO. I had one ‘Intenso’ class 10 card that showed just 115 4K write IOPS and only two write IOPS at 16K block size while other ‘class 10’ rated cards that were not even more expensive showed 300 times better scores. One year ago Samsung EVO/EVO+ with 32 GB and 64 GB had the best performance/price ratio when it was about random IO (just search the web for ‘SD card performance site:armbian.com’) but unfortunately this has changed and more recent EVO/EVO+ perform way worse than back then while still being compliant to — sequential transfer speeds only — ‘speed class’ requirements.
So it’s really great that random IO got now covered by some specs (hopefully the same will apply to ‘durability’ sometimes in the future) and I’m already looking out for A1 specified cards made by trustworthy vendors.
Do SBCs need to offer different SD Card drives to support this, or is it all in the SD Card itself?
Also, anyone know if there are any cards smaller than 256GB available for these?
@Mike Schinkel
Forget about SBC here at the moment. Switching voltages (3.3V vs. 1.8V) is required and controller support is mandatory for performance. SD cards compliant to A2 and even A1 performance class will be bottlenecked by bus limitations on most SBC today since there’s so much protocol/bus overhead if the board’s implementation is not up to date. It’s easy to test: just use a capable IO test with 4K block size (or less) and check sequential transfer speeds. If sequential transfer speeds are already low then random IO will also suffer since the limitation at this stage is already ‘transferring 4K of data between host and device’.
This is somewhat comparable to the situation with high performance flash storage today: take PCIe attached SSDs and compare old AHCI interface (protocol layer known from traditional SATA from last century made for spinning rust and single core ultra slow CPUs) with NVME. Same SSD will perform magnitudes faster if not any longer bottlenecked by AHCI.
IMO the most important thing with A1 and A2 performance classes is raising awareness at customers. Today’s SD card users know only irrelevant speed classes and aren’t aware that they can buy ‘class 10’ cards from ‘renowned’ brands that perform 50 times worse than others with the same speed class rating sold for the same price. Rule of thumb: buy SD cards only from vendors producing both NAND dies and controllers (AFAIK only 4 at the moment, 2 names start with ‘S’ and 2 with ‘T’).
Does this mean the end for Samsung’s UFS Card that was revealed last year? I hope we are not going to see a VHS/Betamax standards competition develop in the micro storage card market.
@LloydS
Why do you compare UHS extensions with UFS? UHS II and III is ‘just’ extending already existing SD standards, needing more pins compared to older modes and it’s all about doubling frequency and bandwidth while remaining backwards compatible whereever possible.
UFS is something different, it’s a newer open standard originally meant for internal use only (overcoming limitations of ‘raw NAND’ and eMMC) and just recently JEDEC introduced JESD220-2 standard for removable UFS cards. Samsung currently is the only manufacturer of these cards that are incompatible to both SD protocols and pin-outs. So one part of the chicken-egg problem is solved and now it’s up to hardware manufacturers to embed UFS controllers and card slots in devices.
UFS is more modern and made for today’s architectures (parallelism, more efficient), it’s somewhat comparable to AHCI vs. NVME with SSDs as explained above. So new UHS III mode is just another backwards compatible extensions of an old standard while UFS might take over in the future.
Another thing to add: I already mentioned stumbling accross an SD card showing somehow ‘normal’ 4K write IOPS (~100) but horribly low 2 IOPS at 16K size. When we did this testing a while back there were many other SD cards that suffered from the same problem: a mysterious performance drop at 16K block size to below 10 IOPS (affected also many cheap SanDisk cards): https://forum.armbian.com/index.php?/topic/954-sd-card-performance/
Now imagine running a database which uses a 16K page size internally and constant fsync calls to ensure data integrity ‘on disk’. Funnily something like this is happening all the time when running modern OS and applications like web browsers. If your Android on an SBC feels sluggish better check random IO storage performance, same with a Desktop Linux and browsing the web. Here’s a nice read how random IO performance and ‘database settings’ might affect your Firefox browsing experience (same applies to Chrome/Chromium and any other modern browser): https://wiki.mozilla.org/Performance/Avoid_SQLite_In_Your_Next_Firefox_Feature
@tkaiser
Well, thanks for your lucid reply but my concerns remain. If I were currently designing an Odroid Cx (say), I would need to decide whether to:
a) include UHS II or III MicroSD slot and eMMC connector (little change from status quo), or
b) leave out the above and include UFS Card slot instead (saving PCB real estate), or
c) include a UHS II or III MicroSD slot for backward compatibility and UFS Card slot instead of eMMC connector (most likely?).
presuming, of course, that my favoured SoC is capable of supporting all.
Sadly, I do see the UFS Card standard as a competitor with UHS II and III and I’m apprehensive about that
If you would design a new SBC today and want to implement UFS cards the first you would have to check whether those SoCs that are capable of UFS (those from Samsung’s most recent flagship phones) are even JESD220-2 compliant. If not… then you need new SoCs or (PCIe attached) controllers. So let’s talk in 2019 again if the focus is SBC 🙂
Then the other problem with UFS card acceptance is backwards compatibility. You can take an UHS III card that performs quite well in your most recent gadget and insert it in a 10 years old card reader where data can also be accessed (though slow as hell since). With UFS there’s no backwards compatiblity. And I don’t see Apple being involved here (they’re IMO the only vendor capable of forcing market adoption of new innovative standards just by solely using them from one day on and dropping older standards — the price is paid by Apple customers since we’re the ones carrying around a ton of adapters 😉 )
@tkaiser
Depending on the likes of NAND Flash for your OS’s random read/write storage is a bad idea in the first place. Your OS should boot from flash via sequential read, run mostly in SDRAM thereafter, and only write to flash sparingly to reduce wear.
Adata claims to show an SD card compliant to A2 standard: http://industrial.adata.com/a/news/4/
Heise.de just reported they would show the ‘Adata Premier microSD’ with 32, 64 und 128 GB mentioning “up to 4000/2000 IOPS” at Computex which is ‘interesting’ since A2 compliance talks about 4000/2000 IOPS being minimum requirements and not funny ‘up to’ marketing BS. 🙂