Most users are aware that flash memory comes in a variety of speeds and capacities. Early-on, flash manufacturers attached different monikers to their memory to confer their relative speeds (e.g. Ultra, Ultra II, Extreme III, Extreme IV), which were sometimes confusing. Other manufacturers placed speed ratings, denoted by an “X”, where 1x referred to the CD-ROM transfer rate of 150kB/s. Others placed “vague” rates such as “Up to 20Mb/s” on their labels, none of which are clear as to whether this referred to read or write rates.
Unfortunately this made for confusion and disappointment as many of those ratings were made using specific conditions set by the manufacturer which were not always clear, and sometimes the ratings referred to read as opposed to write speeds (especially for lower end, low cost cards) as read speeds are easily achieved in comparison to write speeds.
To address the growing need for reliable, faster storage with the advent of High Definition video and high resolution RAW photo shooting, the SD Association introduced the Class-rating system which defined a set of class levels for a guaranteed level of write performance under fragmented conditions. These would be based upon testing to the SD Association’s rules. These included Class 2, Class 4, Class 6 and Class 10 for a guaranteed speed of 2Mb/s, 4Mb/s, 6Mb/s and 10Mb/s respectively.
Lately, the original SD transfer mode of 25Mhz “double data rate” clocking with 4-lanes reaching a theoretical 25MB/s became a significant bottleneck, which led to the development of higher-clocked modes. These collectively were referred as the UHS modes, with UHS-I being now widely available.
Faster is Better?
For the most part, this allowed consumers to get a better idea of how the cards would perform for most of their use cases – e.g. within a digital camera. Cards with higher speed grades or UHS-I designation are likely to perform better than those with lower designations in general.
Unfortunately, this doesn’t give us the complete picture. Each card’s performance is a function of the type of flash used (SLC, MLC, TLC with varying page sizes and interfaces which affects program times and error rates), the number of channels, and controller (wear-levelling, block management, ECC).
This results in a minefield of possible issues, one of which is compatibility (e.g. SDSC, SDHC, SDXC and controller “violations” of the specifications). Despite cards being advertised as “compliant” to the SD specification, you may occasionally find a card which behaves “slowly” or incorrectly with certain devices, leading to data corruption or loss. Likewise, readers and other devices may not clearly state whether they support certain cards and transfer modes, and become the “bottleneck” of an otherwise fast card.
When using SD cards for purposes other than with digital cameras, small block accesses can become dominant and the performance of the cards in this regard can vary widely. A very common use of cards other than digital cameras is for expansion of storage on laptops, tablets and smartphones which may involve running applications from the storage, or the use of embedded system platforms running Linux on the SD card itself, such as the Raspberry Pi, Beaglebone Black etc. Arguably, in these situations, a card with the best combination of sequential, random, large and small block access speeds would be the best choice.
The class rating of the card is not sufficient to know exactly how the card will behave under any other workload than the one that was tested! The cynical side of me thinks that controllers may be optimized to pass these workloads better just to qualify for higher class numbers.
In order to systematically understand the differences between cards, I spent two continuous days working to make it all happen. The important thing to realize is due to chipset differences in readers and latency due to the USB 3.0 bus, results I achieve here will be different to the results you may achieve with your own rig. As a result, it was my priority to test as many cards as I had access to in order to make a database with results that could be compared relative to one another, although absolute sequential speeds are likely to approach the true card limit.
My test rig consists of a Gigabyte 890FXA-UD7, AMD Phenom II x6 1090T @ 3.90Ghz, Windows 7 x64 Ultimate Edition, Transcend RDF8 USB 3.0 card reader, and Renesas/NEC uPD720200 USB 3.0 controller. The software used was CrystalDiskMark x64 Version 3.0.2, configured to use the average of five runs on a a 1000Mb test file with random fill to avoid compression effects.
Many of the cards were already in use, so in order to ensure consistency, the cards had their contents backed up and formatted with SDFormatter V3.1 with full overwrite and size adjustment on in order to ensure alignment and fresh card state. Filesystem used in test was FAT (2Gb), FAT32 (4Gb-32Gb inclusive), exFAT (>32Gb) as most often used with memory cards and mandated by the SD Association (but not necessarily what you will use!)
The results have been aggregated into a table below:
Additionally, the card data area size is computed from CSD register data and matches the SDFormatter block number readout. This was to illustrate the diversity in card data area size.
For the most part, sequential performance provided little or no surprise. In general, it’s clear to see that the read speeds often exceeded the write speed, hence the motivation for manufacturers of slower cards to quote the read speed as it’s the larger figure.
Interestingly, the write speeds varied somewhat – UHS-I rated cards were often labelled with Class 10, however, their performance often exceeded Class 10 margins significantly (hence the manufacturer also states the transfer rate). In one case, the Sandisk Ultra 64Gb UHS-I microSDXC did not reach its stated Class 10 rate with sequential writes, this may be timing related.
Class 10 cards proved to be a mixed bunch – two of the three cards were twice as fast as the 10MB/s requirement on sequential, whereas the Samsung was much closer to the 10MB/s requirement. As they were not capable of utilizing UHS-I signalling, they were limited to a theoretical 25MB/s transfer rate, which was very nearly reached in many cases.
Class 4 cards and unclassed cards provided a fairly similar spectrum of performance – some cards were much faster on the read (the later made cards, possibly due to newer controllers), although the element14 supplied card is likely a UHS-I card with Class 6 performance rather than the Class 4 which it was labelled. This can be seen due to its blistering read performance, but somewhat slower (but still exceeding 4MB/s) write speed.
The read speeds ranged from a low of 11.78Mb/s to 83.56Mb/s, with write speeds ranging from 5.357Mb/s to 64.140Mb/s.
Medium and Small Block Performance
When we come to medium and small block performance, a bigger variance in performance is seen. Focusing on the UHS-I cards, in general, the performance is not too bad, although likely due to timing issues, the Sandisk Ultra 64Gb UHS-I microSDXC put out a very unusually fast 512k write speed, where most of the UHS-I cards tested seem to be mediocre to poor at 512k writes. 4k performance is “good” across the board, which was unexpected, as the generally accepted trend is that faster larger cards are necessarily worse at small block random accesses due to larger flash pages and erase penalties.
The Class 10 results provide a very interesting result, with some of the slowest 4k write speeds in the list, along with some of the unclassed cards. In general, the performance of the Patriot and Team cards for medium and small block is average to poor.
Of the Class 10 cards, the Samsung which was slowest at sequential write is actually a good all-rounder, demonstrating good to excellent performance at medium and small blocks for its class!
Class 4 cards show an even more interesting trend – while not universal, they suffered in sequential performance, but two of the three showed excellent 4k write performance, although this did not carry over to 4k read or 512k block performance at all. The other card demonstrated better 512k performance but poor 4k performance.
Unclassed cards were generally poor at 4k writes, but some were acceptable to good on 4k reads and 512k writes. 512k reads weren’t as good as they are outpaced by their UHS-I and Class 10 brethren.
Overall Access Speeds
Before I get into this part, it’s important to realize that UHS-I rates will not be available to any controllers unable to communicate at that signalling rate. As a result, the UHS-I performance is unlikely to be seen on embedded platforms (such as the Raspberry Pi), so instead, the performance will be capped to a “25MB/s” or below level.
That being said, this is rarely an issue for non-sequential access as most cards are hideously slow when random writes are involved. That being said, very few cards are good across the board when it comes to different types of access – the Samsung 32Gb Class 10 SDHC seems to stand out as the one with a good balance of rates, as does the Sandisk Ultra 64Gb UHS-I microSDXC. Also deserving of an honourable mention is the Toshiba Exceria Type 2 64Gb UHS-I SDXC.
That being said, if your workload is mostly 4k writes, the fastest 4k write card is actually a Class 4 card! So higher class is not necessarily better – the Team 32Gb Class 10 recorded the equal second slowest 4k write rate – that of an unclassed card!
If your workload is mostly 4k reads, the Kingston 32Gb Ultimate UHS-I SDHC does very well, closely followed by the Toshiba Exceria Type 2 64Gb UHS-I SDXC.
Unfortunately, there is no magic bullet here – each card has its own personality!
Usable Data Area
I decided to throw this part in just to illustrate the unfortunate issue of varying capacity. One of the cards was not in my possession (earlier CrystalDiskMark results with the same set-up were used), so I couldn’t determine its size in bytes.
While flash memory is generally sold in binary quantity, it is common for manufacturers to provide the decimal quantity (sometimes called weasel gigabytes especially when it referred to the Hard Disk practice of providing decimal quantities of bytes). This serves a feature in order to overprovision the flash memory to allow for replacement of bad blocks, failing blocks and rotation of data for wear levelling. More advanced designs may use it as a cache as well.
Unfortunately, the way this is performed results in varying card capacity sizes, making it hard to develop an image of a card and restore that to another brand without potentially truncating the end!
It also makes it a bit annoying to the consumer – if they purchased a 128Gb card, they may naively assume they get 128GiB = 137,438,953,472 bytes. A more advanced consumer might assume they get 128Gb = 128,000,000,000 bytes. But they’re both wrong – Kingston gives you just 125,342,580,736 bytes! That’s 125 weasel gigabytes, or 116.734375 GiB!
Of course, not all the tested cards were “below” the weasel mark – although more recent cards seem to be below the weasel Gb mark. Looking at 32Gb cards, the Samsung provides the least space at 31,393,316,864 bytes, whereas the Patriot LX is generously providing 32,107,397,120 bytes – a difference of 681 MiB, almost a full CD’s worth.
I often wish manufacturers would publish the size of their devices to ensure we are informed exactly how big they are. Hard drive manufacturers do this by specifying the number of LBAs (sectors) are addressable – and for the most part, any 2Tb hard drive of modern provenance has the same number of sectors regardless of manufacturer.
With this lot of data that covers virtually every SD card I have in reach of me, it’s clear that the performance of the cards vary wider than previously thought, and the class system is not completely telling in predicting small block and medium block performance. Likewise, the performance recorded in this benchmark is really only indicative of the performance with the given Transcend RDF8 reader attached to the Renesas uPD720200 USB 3.0 bus on my main workstation – each device will see its own limitations (e.g. no support for UHS-I modes), or even advantages (higher IOPS due to less command latency).
Regardless, as the data comes from one consistent configuration, it allows for more reliable relative analysis, which shows that there are some cards which are more consistent in performance across the board, but they’re relatively rare – there is no one virtuous card which has everything we’re looking for, although it is interesting to note that the performance of Class 4 cards are virtually identical to the unclassed cards which makes me puzzled as to the existence of Class 2 (don’t buy them!)
Variations in 4k small block performance saw a difference of approximately 300-fold between the fastest and slowest cards. Distressingly, many of the tested cards were mediocre to poor on that metric, which may explain why running updates on Linux running off SD cards can take a very long time.
The benchmarks were not without anomalous results – in some cases, in what appears to be timing related (possibly due to controller housekeeping), we see the Sandisk 64Gb microSDXC with a faster 512kB random write than sequential (hmm!), and the Toshiba Exceria with a higher 4k QD32 read compared to 4k read (hmm – most of them are virtually identical since SD cards have no native queueing to my knowledge). This points to an even more dynamic behaviour than can be captured with this benchmark – interleaved reads and writes to certain blocks in certain orders may provoke unusually fast or slow behaviour.
The size of the cards are also inconsistent, which may mean it would be wise to develop partitioning schemes where there is a lot of excess space at the end to accommodate easier cloning to other smaller cards.
Maybe one should buy a few cards, if they can afford the luxury, and test, then choose to use the ones which fit the best for their applications.
Bonus: More CID/CSD dumps
As a result of testing, I managed to collect two more CID/CSD pairs – just in case anyone was interested in seeing some for reference:
Sandisk 4Gb Class 4 microSDHC CID: 035344535530344780811ea6ab00b37f CSD: 400e00325b5900001d8a7f800a4040b9 Sandisk 1Gb microSDSC CID: 0353445355303147800008fe40006cfd CSD: 002600325f5983c8befbcfff924040d7