When people plan to use a development board for their project, they mainly focus on the requirements of the development board itself, as well as software support. But selecting the right accessories may be just as crucial for good performance and stability. For example, selecting a proper power supply is important, as the board may freeze or randmly rebooted if it is not feed at the right voltage. Part of this is selecting a micro USB cable, as you’ll want a cable with minimal resistance which can be achieved through shorter cables and/or a low AWG value. Another important item that can impact stability and performance of the systems are micro SD cards when used to run the operating system in development boards.
Understanding SD Card Performance Metrics & Classes
Until a few years ago, (Micro) SD cards were primary used to store data such as photos, videos and music. In those use cases, you have large files that benefit from high sequential read and write speeds. That’s why the SD association created different classes to specify a minimum write speed with speed class, UHS speed class, and more recently Video Speed Class.
That’s useful as you won’t need the same write speeds to copy music files, or record videos in a 4K camera, and the cards with a lower class are normally cheaper. Note that most (all?) low cost development board do not support UHS-II or UHS-III interface, so it may work, but you won’t be able to reach the maximum performance of the card. Micro SD card controllers are also often connected via SDIO which limits the sequential performance to around 23 MB/s.
However, those classes are only marginally useful for micro SD cards used in development boards, since operating systems generate a lot of small read and write operations, for example for databases and web caches, rather than handling large files. That’s why storage devices may also include read and write IOPS (I/O per seconds) which are more useful for this type of use case. The table below about Samsung eMMC and UFS flash chip shows some of those numbers.
The only problem is that until very recently, there was no way you could know minimal IOPS R/W numbers for SD cards since they were simply not made available by the manufacturers, so instead people were recommending Class 10 micro SD cards which may or may not best suited to their use in development boards. However, since the introduction of Adoptable Storage in Android, where micro SD cards could be used for apps instead of just data, IOPS values became more important, and the SD association has now introduced Class A1 & Class A2 application performance classes for SD cards specifying minimum IOPS R/W values together with a 10MB/sec minimum sustained sequential write speed.
That’s great! Problem solved then? Not quite, as manufacturers have only started to use application performance class logos in their higher-end SD cards with high capacity like 256GB, which usually cost several times the price of your typical development board. So we need to rely on the community to test IOPS R/W values, or random read and write speeds.
Software Tools for SD Cards
There are several program that can test performance. hdparm and dd are popular, but the former only test sequential speed for a very short time, and the latter only test sequential speed, and many people may not include the time it takes to flash the cache to the actual card (e.g. with sync), leading to potentially misleading results, and mostly irrelevant to our use case.
So instead, there are specific tools to tests both sequential speeds and random I/O performance. Bonnie++ is one, but recently iozone has become the reference for disk I/O testing, and that’s the one used in the benchmarks below.
Many tutorials recommend to flash firmware using Win32DiskImager in Windows, or dd in Linux. However, while I have not experience the issue myself, I’ve been told the latter may not always detect errors while flashing, and a new tool is now recommended: Etcher. It works in Windows, Linux, or Mac OS using a GUI or the command line, and will verify the SD card after flashing making sure nothing has gone wrong during the process.
SD Cards Benchmarks
With that in mind we need micro SD cards with good random R/W performance, which we can test with iozone3, and for many applications 8 to 32 GB capacities are enough. We were planning to test ourselves, but Andreas Spiess has already published a videos – embedded further below- leveraging pidramble work, with benchmarks using several micro SD cards on a Raspberry Pi 3 board. You’ll also find more results and discussion on Armbian forums. Linaro also made a survey of micro SD cards a while ago.
Here are the main takeaways from the tests:
- Larger cards are usually faster but not always (See Samsung EVO+ 64GB results).
- Benchmarks vary a lot between runs for a given card with 10 to 20% variations
- Most low cost micro SD cards / clones have really bad random write performance.
- Samsung and Sandisk cards get the best random I/O performance
- It’s not always necessary to buy the most expensive cards for usable performance.
The conclusion is that for the best performance select cards like Samsung EVO+ 32GB or Samsung Pro+ 32GB selling for respectively around $18 and about $25 on Amazon US. A cheaper card that should work decently is Sandisk Extreme Pro 8GB sold for $8.
The Problem of Fake Micro SD Cards
It looks like we have now found a decent list of micro SD cards to use with our development boards. There are still problem has some are copy, even on sites like Amazon , as manufacturer of fake card may insert them in the supply chain. One way to double check if you have an original is to check the CID (Card Identification) number. In Linux, you can do so as follows:
|
1 2 |
cat /sys/block/mmcblk0/device/cid 035344534c3038478049731d9201063d |
The first two digit represents the manufacturer ID. There’s no public list, but “1b” is for Samsung. You can decode the full CID on here.
If you’ve bought a Samsung SD card, and the Manufacturer ID is different from 0x1b, then you almost certainly have a fake Samsung SD card. If the number is 0x1b, you can’t be 100% sure you have a genuine SD card however, as the clones may have also cloned that part.
Sadly there’s no easy other way to check if a card is real or fake. Checking the performance is similar to other reports online may help confirm you have a proper card. That 2010 article by Bunnie has more details about fake SD cards.
Longevity and Reliability of microSD Cards
I’ve been using micro SD cards for about 5 years both in development boards, and my phone, and I have to say I’ve had to throw away many of them due to I/O errors after a while. I’ve also found my card readers also only last a few months. So far, I mostly bought cheaper ones, so it could be an explanation. Sadly, manufacturers do not provide any MTBF (Mean Time Between Failure) for SD cards so there’s no data like on hard drives and SSDs.
However, there are ways to limit wear and tear on micro SD cards by limited writes, either by making the rootfs read-only which is fine for embedded projects, less if you plan on using your board as a computer, or using log2ram, extending the write buffer commit interval, etc… More discussion about SD card lifespan can be found on Pete Scargill’s blog.
Some people will also encounter corrupted flash that won’t boot anymore after a power failure or a crash because the file system has been corrupted. It is not directly related to the SD card itself, and it’s more likely to occur if you have a poor power supply. Steps to reduce the probably of corruption involves the same steps as previously mentioned to limit wear and tear with a read-only file system and so on.
Another solution to avoid most the issues mentioned above is to use boards with eMMC flash, but of course going that route would mean that you’d have to avoid Raspberry Pi boards, baring the RPi Compute Module. Neverhteless, a combination of carefully selected power supply, USB cable, and micro SD card should still give you a good experience, and avoid many potential headaches, with your board.
Thanks to Karl and Thomas for tips and insights.
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
