microSD card performance comparison

[falk.ben@gmail.com]

I thought it would be nice to have some microSD card performance numbers so people can pick the right card for their application.

I used the same tests as explained here: http://www.jeffgeerling.com/blogs/jeff-g...crosd-card

I have two SD cards:

• PNY U3 Turbo Performance 32GB Class 10 UHS-I
  
• Transcend 32GB MicroSDHC Class10 UHS-1
  

DISCLAIMER! Collective benchmarking has its pitfalls.  Do not take these results to be the final word.  Be aware that there are fake cards floating around masquerading as top notch cards.  Also be aware of the fact that manufacturers will update the same model SD card with different hardware but not update the model name.  If performance is important to you, seek additional information when purchasing new cards.  This is only meant to provide additional information, and may be false.  You have been warned

Now, with that out of the way, you can view the performance table here:
https://docs.google.com/spreadsheets/d/1...mO1qs/edit

[Andrew2]

You can see the results here:
https://docs.google.com/spreadsheets/d/1...mO1qs/edit

Maintaining such a table is pretty useless unfortunately since result tables already exist (made with 'non fake' SD cards) and since a huge amount of people really think they could buy a recommended SD card that costs $25 normally on Aliexpress for $8 instead.

Then they end up with a fake card with less capacity/performance/reliability but it's hard to convince them that they bought crap. That's the reason why we added to our user documentation two links how to check for bad cards, two links how to choose a better one (already containing your link from above) and in the meantime an own utility to check SD cards even if they're already in use.

https://github.com/igorpecovnik/lib/blob...re-sd-card

[janjwerner]

You can see the results here:
https://docs.google.com/spreadsheets/d/1...mO1qs/edit

Maintaining such a table is pretty useless unfortunately since result tables already exist (made with 'non fake' SD cards) and since a huge amount of people really think they could buy a recommended SD card that costs $25 normally on Aliexpress for $8 instead.

Then they end up with a fake card with less capacity/performance/reliability but it's hard to convince them that they bought crap. That's the reason why we added to our user documentation two links how to check for bad cards, two links how to choose a better one (already containing your link from above) and in the meantime an own utility to check SD cards even if they're already in use.

https://github.com/igorpecovnik/lib/blob...re-sd-card

I respectfully disagree. The provided information with links to amazon is helpful.
Sure you will have variations between units of same type, but that table gives you a ballpark figure ( and with the crowdsourcing effort may contain more information than the link provided above).
Given that not everyone has gazillion of cards lying around to test and know what to choose, and granted that some of those cards are in same price range but offer drastically different performance having that information does help.
And about aliexpress - there are things to buy there, and things to avoid. Knowing the counterfeit market of usb sticks / memory cards I would use more trusted ( non-marketplace) vendors.

[falk.ben@gmail.com]

Maintaining such a table is pretty useless unfortunately since result tables already exist (made with 'non fake' SD cards) and since a huge amount of people really think they could buy a recommended SD card that costs $25 normally on Aliexpress for $8 instead.

Then they end up with a fake card with less capacity/performance/reliability but it's hard to convince them that they bought crap. That's the reason why we added to our user documentation two links how to check for bad cards, two links how to choose a better one (already containing your link from above) and in the meantime an own utility to check SD cards even if they're already in use.

https://github.com/igorpecovnik/lib/blob...re-sd-card

"yeah? well, you know that's just like uh your opinion" - The Big Lebowski

Seriously though, if you don't want to use it, don't use it!

I don't know why everyone is going on about fake SD cards.  Do you think my cards are fake?  I purchased the cards at Amazon and would expect any reputable dealer to not be selling fake cards.

On your other points, not everyone is using armbian or has access to that tool to check for bad cards.  I tried installing your tool, but it's not trivial on arch linux with aarch64 (especially for a novice like myself).

However, this spreadsheet isn't really meant as a test for bad cards.  This is meant to benchmark a variety of cards to help people select a card for best performance.  And I also have no problem with adding performance numbers from armbianmonitor.

The SD cards I tested are not in the table of benchmarked cards linked above.  We also might expect performance to be slightly different from the Raspberry Pi 2, which is what was used in the benchmark I linked.  

I think all these reasons taken together justify creating a new table of benchmarked cards.  But, as I said, if you don't want to use it, no one is forcing you to.

[Andrew2]

I respectfully disagree. The provided information with links to amazon is helpful.
Sure you will have variations between units of same type

Yeah, I could submit for the very same label (not card!) 'SanDisk Extreme Pro 8GB UHS-I' 3 different results that vary a lot. All tested in the same board. How's that possible? Since I sit in front of the 3 cards I could notice the differences (gold vs. black and obviously the two black ones from different years showing different random I/O performance).

Will users that submit results for their card take notice? Nope, since they don't even know that these differences exist when they don't own a couple of cards. So this will be a collection of performance numbers partially without meaning (or only of historical interest).

If I already bought a card I should test it always myself and never rely on results published in a spreadsheet somewhere since not performance numbers in a spreadsheet matter but my card's performance (see above: Which of the 3 results to choose from if users start to submit conflicting results? Most probably simply the first entry you stumble accross) . 

It should be noted that you can buy fake cards everywhere and it's also not that hard to enter the words 'amazon fake micro sd card' or 'amazon counterfeit micro sd card' into a search engine to start to understand that the supply chain (where the fake products origin from) does not start at the retailer but somewhere in Asia. It's impossible for a big retailer to protect you from buying fake cards, the only chance you have is to immediately test the card you receive and return it asking for a refund when you got a fake card.

So this spreadsheet will be filled partially with meaningless results and as a user you can't rely on the results published there since they have zero relevance for the card you bought. So why looking into it anyway? If you search for a performant card (especially random I/O) then why searching through a spreadsheet collecting all sorts of questionable cards (or results) when there are also lists available that only collect top performers worth a buy? The most important factor for any SD/TF card used with an SBC is random I/O! Therefore it's close to moronic to choose anything else than the 5 top performers when it's about to buy a new card.

Regarding comparison of the results it's also pretty easy. Both RPi and Pine64 max out regarding sequential transfer speeds at approx. 22MB/s. If you see lower results then it's most probably the card's fault and if you see ~22MB/s then you know it's fast enough regarding sequential transfer speeds. Regarding random I/O it only depends on the card in question. In other words: The two tables containing well known top performers can be used for Pine64 without any doubt.

---

I think all these reasons taken together justify creating a new table of benchmarked cards. But, as I said, if you don't want to use it, no one is forcing you to.

I won't use this table for sure since I sometimes do benchmarking for a living. Without controlling every detail the chance that you collect numbers without meaning is pretty high, especially on Linux/Unix where background jobs might render benchmarks results useless easily.

People will submit results showing bad sequential/random I/O not caused by the card but since they played a bit around while testing, a cronjob in the background has been busy updating locatedb or the system is doing unattended package upgrades while they ran the single test execution they blindly trust in. Running benchmarks in a 'fire and forget' manner is always wrong but will be the default when random people submit random results.

I know that people love numbers (so easy to compare) and almost never think about the meaning of these numbers or whether they can be trusted or not. Or in other words: results that have been measured correctly (repeating the test at least 3 times and controlling setup/procedure using approriate tools -- iotop/iostat in this case) will be a rare exception.

I hope that sounds not rude but at least discouraging enough to stop the whole approach? :-)

[janjwerner]

I respectfully disagree. The provided information with links to amazon is helpful.
Sure you will have variations between units of same type

Yeah, I could submit for the very same label (not card!) 'SanDisk Extreme Pro 8GB UHS-I' 3 different results that vary a lot. All tested in the same board. How's that possible? Since I sit in front of the 3 cards I could notice the differences (gold vs. black and obviously the two black ones from different years showing different random I/O performance).

Will users that submit results for their card take notice? Nope, since they don't even know that these differences exist when they don't own a couple of cards. So this will be a collection of performance numbers partially without meaning (or only of historical interest).

If I already bought a card I should test it always myself and never rely on results published in a spreadsheet somewhere since not performance numbers in a spreadsheet matter but my card's performance (see above: Which of the 3 results to choose from if users start to submit conflicting results? Most probably simply the first entry you stumble accross) . 

It should be noted that you can buy fake cards everywhere and it's also not that hard to enter the words 'amazon fake micro sd card' or 'amazon counterfeit micro sd card' into a search engine to start to understand that the supply chain (where the fake products origin from) does not start at the retailer but somewhere in Asia. It's impossible for a big retailer to protect you from buying fake cards, the only chance you have is to immediately test the card you receive and return it asking for a refund when you got a fake card.

So this spreadsheet will be filled partially with meaningless results and as a user you can't rely on the results published there since they have zero relevance for the card you bought. So why looking into it anyway? If you search for a performant card (especially random I/O) then why searching through a spreadsheet collecting all sorts of questionable cards (or results) when there are also lists available that only collect top performers worth a buy? The most important factor for any SD/TF card used with an SBC is random I/O! Therefore it's close to moronic to choose anything else than the 5 top performers when it's about to buy a new card.

Regarding comparison of the results it's also pretty easy. Both RPi and Pine64 max out regarding sequential transfer speeds at approx. 22MB/s. If you see lower results then it's most probably the card's fault and if you see ~22MB/s then you know it's fast enough regarding sequential transfer speeds. Regarding random I/O it only depends on the card in question. In other words: The two tables containing well known top performers can be used for Pine64 without any doubt.

---

I think all these reasons taken together justify creating a new table of benchmarked cards. But, as I said, if you don't want to use it, no one is forcing you to.

I won't use this table for sure since I sometimes do benchmarking for a living. Without controlling every detail the chance that you collect numbers without meaning is pretty high, especially on Linux/Unix where background jobs might render benchmarks results useless easily.

People will submit results showing bad sequential/random I/O not caused by the card but since they played a bit around while testing, a cronjob in the background has been busy updating locatedb or the system is doing unattended package upgrades while they ran the single test execution they blindly trust in. Running benchmarks in a 'fire and forget' manner is always wrong but will be the default when random people submit random results.

I know that people love numbers (so easy to compare) and almost never think about the meaning of these numbers or whether they can be trusted or not. Or in other words: results that have been measured correctly (repeating the test at least 3 times and controlling setup/procedure using approriate tools -- iotop/iostat in this case) will be a rare exception.

I hope that sounds not rude but at least discouraging enough to stop the whole approach? :-)

Brutally honest as usual, this time adding more to the discussion
I would say use model a / model b since this is what I have tested, it's running pretty well for me and is reasonably priced.
In my opinion people who want the best performance will try several cards on their own and make up their own mind. However, in my opinion many members of this community come here for reasonably simple answers. Saying: buy whatever, then test it using this suite of tests, then if it doesn't work buy something else simply doesn't cut.
I do believe some people do appreciate statement: I tested this card, it works for me and I got decent performance. I don't expect that anyone outside of this community will use the results, however I wouldn't completely discredit the information just because it's not up to your benchmarking standards. (hey I praise you for being thorough and getting the details right!)
finally
I use:
Sony 32gb microSDHC Memory Card (SR32UY2A/TQ) works OK (16mb/s sequential read/write)
Sandisk Extreme 32GB U1 micro SD card (SAEMSD32GBQ) worked much better ( 23mb/s with sequential read / write)
Sony cards were $7 each few weeks ago, Sandisk was $25 two years ago.
cheers

[falk.ben@gmail.com]

I respectfully disagree. The provided information with links to amazon is helpful.
Sure you will have variations between units of same type

Yeah, I could submit for the very same label (not card!) 'SanDisk Extreme Pro 8GB UHS-I' 3 different results that vary a lot. All tested in the same board. How's that possible? Since I sit in front of the 3 cards I could notice the differences (gold vs. black and obviously the two black ones from different years showing different random I/O performance).

Will users that submit results for their card take notice? Nope, since they don't even know that these differences exist when they don't own a couple of cards. So this will be a collection of performance numbers partially without meaning (or only of historical interest).

If I already bought a card I should test it always myself and never rely on results published in a spreadsheet somewhere since not performance numbers in a spreadsheet matter but my card's performance (see above: Which of the 3 results to choose from if users start to submit conflicting results? Most probably simply the first entry you stumble accross) . 

It should be noted that you can buy fake cards everywhere and it's also not that hard to enter the words 'amazon fake micro sd card' or 'amazon counterfeit micro sd card' into a search engine to start to understand that the supply chain (where the fake products origin from) does not start at the retailer but somewhere in Asia. It's impossible for a big retailer to protect you from buying fake cards, the only chance you have is to immediately test the card you receive and return it asking for a refund when you got a fake card.

So this spreadsheet will be filled partially with meaningless results and as a user you can't rely on the results published there since they have zero relevance for the card you bought. So why looking into it anyway? If you search for a performant card (especially random I/O) then why searching through a spreadsheet collecting all sorts of questionable cards (or results) when there are also lists available that only collect top performers worth a buy? The most important factor for any SD/TF card used with an SBC is random I/O! Therefore it's close to moronic to choose anything else than the 5 top performers when it's about to buy a new card.

Regarding comparison of the results it's also pretty easy. Both RPi and Pine64 max out regarding sequential transfer speeds at approx. 22MB/s. If you see lower results then it's most probably the card's fault and if you see ~22MB/s then you know it's fast enough regarding sequential transfer speeds. Regarding random I/O it only depends on the card in question. In other words: The two tables containing well known top performers can be used for Pine64 without any doubt.

---

I think all these reasons taken together justify creating a new table of benchmarked cards. But, as I said, if you don't want to use it, no one is forcing you to.

I won't use this table for sure since I sometimes do benchmarking for a living. Without controlling every detail the chance that you collect numbers without meaning is pretty high, especially on Linux/Unix where background jobs might render benchmarks results useless easily.

People will submit results showing bad sequential/random I/O not caused by the card but since they played a bit around while testing, a cronjob in the background has been busy updating locatedb or the system is doing unattended package upgrades while they ran the single test execution they blindly trust in. Running benchmarks in a 'fire and forget' manner is always wrong but will be the default when random people submit random results.

I know that people love numbers (so easy to compare) and almost never think about the meaning of these numbers or whether they can be trusted or not. Or in other words: results that have been measured correctly (repeating the test at least 3 times and controlling setup/procedure using approriate tools -- iotop/iostat in this case) will be a rare exception.

I hope that sounds not rude but at least discouraging enough to stop the whole approach? :-)

So to summarize, it seems like your argument is that bad information is worse than no information.

I would simply argue that more information is better, and let everyone decide for themselves.  I will add another column to the table with the username from this forum, so that people feel some sort of responsibility, and I will also be adding a short disclaimer to the top post here, so that everyone is aware of the pitfalls of collective benchmarking.  I appreciate your criticism, and if you have benchmarking to add from those three cards with the same model name, I would greatly appreciate it being added to the table.  I think it's good to know that the same model card could perform quite differently, depending on the batch.

---

I use:
Sony 32gb microSDHC Memory Card (SR32UY2A/TQ) works OK (16mb/s sequential read/write)
Sandisk Extreme 32GB U1 micro SD card (SAEMSD32GBQ) worked much better ( 23mb/s with sequential read / write)
Sony cards were $7 each few weeks ago, Sandisk was $25 two years ago.
cheers

Could you do 4K read/write test?  For sequential read/write were you using hdparm or dd?

[Andrew2]

However, in my opinion many members of this community come here for reasonably simple answers.

This is what I try to provide. Users should learn 3 things regarding SD cards:

• random I/O is more important than sequential speed, so if you want to buy a new card choose one that shines here. The speed class won't tell you anything in this regard therefore choose any of the 5 top performers from the aforementioned 2 benchmark comparisons
  
• fake SD cards exist and are a real problem (less capacity, less performance, less realiability), you get them even from 'quality retailers' so test your card immediately. Speed results that are published somewhere for a card that is labeled as yours do not matter since you have to check yourself if you got a fake card or not to be able to get a refund and buy a good one instead
  
• Use this simple tool to check your card (for most users this might be H2testw running on their Windows machine before they start writing an image to the card and while H2testw won't tell you anything about random I/O it shows sequential speeds which is enough to identify fakes as well)
  

 (you might notice that this is still the same I said in my first post in this thread)

BTW: If you look at the numbers from Jeff Geerling we rely on... they're also wrong! He never exceeds 18.5 MB/s for sequential speeds which is an indication that something's wrong with his settings, most probably using ondemand scheduler without approriate I/O settings. Since the specific SDIO implementation of both RPi and Pine64 is limited to ~22MB/s:

Code:

root@RPi2:/sys/devices/system/cpu/cpu0/cpufreq# hdparm -t /dev/mmcblk0

/dev/mmcblk0:
Timing buffered disk reads:  66 MB in  3.02 seconds =  21.84 MB/sec

Small ARM boards behave differently than x86 PCs and wrong CPU settings also affect I/O performance. Do your users know that when submitting results? Some basics: http://linux-sunxi.org/SATA#Performance

So in fact your users are testing different cpufreq governors combined with different settings (might make a difference of up to 5-6 MB/s when testing sequential speeds), different I/O schedulers and different IRQ distribution settings but think they test their cards. There will be OS images that take care of the aforementioned stuff (thinking of Armbian when available sometimes) and there will be some that don't and might use settings that lead to killed CPU cores due to overheating before (then performance will even drop lower and submitted results are even more meaningless).

So while even Jeff Geerling's numbers aren't measured correctly these numbers have a value unlike the ones from the spreadsheet you try to fill here. Since we can assume that he tested all the cards with nearly identical settings and the only purpose of his list is to identify the 5 top performers regarding random I/O (and for this purpose his and the other list are pretty useable).

So please feel free to ignore any of the aforementioned background information and collect further numbers without meaning. But please refrain from telling users they should rely on any of these numbers for buying decisions or draw conclusions from a table row they found on docs.google.com containing the string 'SanDisk Extreme Pro' for a card they own where 'SanDisk Extreme Pro' is written on. Since it's not possible, there is NO relation between the performance of their device in question and the results someone else wrote in a spreadsheet row sometimes before.

[Andrew2]

Two last remarks:

1) how to interpret these two results?

Code:

root@pine64plus:/# hdparm -t /dev/mmcblk0

/dev/mmcblk0:
Timing buffered disk reads:  18 MB in  3.33 seconds =   5.40 MB/sec
root@pine64plus:/# hdparm -t /dev/mmcblk0

/dev/mmcblk0:
Timing buffered disk reads:  62 MB in  3.08 seconds =  20.14 MB/sec

Are these two different cards? Nope, same card tested with a few seconds in between. Only difference: While the first 'benchmark' ran in another shell I copied a large amount of data to the SD card. Simple conclusion: Writing to the same media affects read speed, 'benchmarks' that run just 3-4 seconds can not be used reliably and their results should not be collected in spreadsheets but thrown away. Seriously, the ext4 default commit interval is 5 seconds so the chance that your 3 second benchmark will be influenced by a write commit is greater than 50%. Using single hdparm runs is therefore meaningless (as it is written in hdparm's manual page but who reads documentation?).

2) Here you can find q&d collected performance results for the 8, 16 (estimated) and 32GB eMMC modules the ODROID-C2 can be used with: http://forum.armbian.com/index.php/topic...c2/?p=6783

Not only sequential transfer speeds are up to 5 times higher than the maximum we get with Pine64's SD card implementation but more importantly the random I/O results are superiour. And that's what matters especially when you want to use a Linux desktop distribution. High CPU performance is nice, being able to use HW acceleration for certain aspects is essential but using an SD card that shows slow random I/O performance vs. using an eMMC module like the aforementioned makes the whole user experience when doing desktop stuff feel as different as day and night.

So if it's about Linux desktop usage either get the fastest SD card available today or think about moving rootfs and especially user homedirs to an USB connected storage device (preferably an SSD in an enclosure that is UASP capable since sooner or later UASP will be either backported or is already available when mainlining efforts for A64 made some progress -- I would suspect A64's USB implementation is the same as H3's so by using kernel 4.x alone sequential transfer speeds will increase by 5MB/s and random I/O might explode if used with a fast SSD in an UASP capable USB enclosure since this is where UASP is way more efficient compared to USB's bulk transfer mode we now have to use)

I made yesterday a quick test with an old 64GB mSATA SSD lying around in this enclosure and moved everything except of the bootloader to it (easy with Armbian). Even without being able to benefit from UASP it's unbelievable how different desktop usage feels.

[falk.ben@gmail.com]

Performance governor is what I was using (it was the default).

I think the comparisons to odroid c2 are off topic. Yes, emmc is faster.

You also link to SATA performance, but we don't have SATA on this board.

I think common sense would dictate that you shouldn't be writing a ton of data to the SD card while taking read benchmarks. Yes, things going on in the background will cause some problems. We can only do as best as we can here. If you follow my spreadsheet, you'll see that for most of the tests I take an average of 2 or 3 tests to reach that number. That should be sufficient to give us a ballpark measure. You'll see the results don't vary much.

I appreciate your criticisms and participation and understand you don't want to contribute or use this data.

We can deal with erroneous test results as they come in. Hopefully enough people will contribute we can build a large data set.

And yes, the evo+ cards are probably the ones people should get. But because I didn't know this, I had two other cards with not as good performance. Would love for someone with the evo+ cards to come in and provide their performance numbers.