
Raspberry Pi microSD card performance comparison - geerlingguy
http://www.midwesternmac.com/blogs/jeff-geerling/raspberry-pi-microsd-card
======
geerlingguy
Main takeaway: Samsung Evo+ (red color) blows away all the other cards
performance-wise, and it's $9.99 at Best Buy right now; 64 and 128 GB cards
also discounted.

The microSD card you use makes a huge difference in how the Pi performs, for
the majority of tasks.

~~~
miahi
One thing: please add the tested card size to the table, as in some cases
there are speed differences between card sizes in the same family.

~~~
geerlingguy
Sorry about that; all are 16GB except the 32GB Evo+, and 8GB Kingston and
SanDisk Extreme Pro.

~~~
Nursie
I wonder if this accounts for some of the EVO+ speed gains over the Sandisk
Extreme... in the past larger cards within the same range were faster.

It may not of course.

~~~
geerlingguy
For sustained writes it always seems to make a somewhat significant
difference, but I haven't found much variation in random IO between different
sizes of the same model card.

~~~
Nursie
Thanks for the info :)

------
fulafel
For comparison, the random 4K write IO rate for a rotating hard disk is ~ 0.4
MB/s given a 10ms seek time. In this benchmark only the bottom 2 cards are
slower than spinning rust.

~~~
pmontra
This is somewhat mitigated by the buffer cache. The random writes are stored
in RAM and hit the disk later on, possibly when it would have been idle. On a
developer laptop there is usually no difference. I remember I run some
benchmarks with a pretty large test suite of a Rails application: POSTGRESQL
in a ramdisk vs spinning disk: no difference in performance because the data
never left the buffer cache. With substantial amount of data you hit the disk
and solid state memory wins.

~~~
fulafel
If your PG setup leaves writes sitting in the buffer cache after transaction
commits, it's not working right.

~~~
pmontra
I'm sure that it persists them to disk but the test suite keeps running at the
same speed, so it must happen when it's less inconvenient. Buying enough RAM
to cache there all the DB is a common recommendation even if it can need some
careful configuration [http://dba.stackexchange.com/questions/18484/tuning-
postgres...](http://dba.stackexchange.com/questions/18484/tuning-postgresql-
for-large-amounts-of-ram)

~~~
fulafel
Still sounds like it's not working right, unless it was a read-only test.
Transaction commits force synchronous disk writes, meaning the transaction
operation will not finish and return before the spinning disk has physically
done one or more disk writes. (Unless you have an expensive storage system
with non-volatile cache memory)

~~~
pmontra
I don't think you can count on the file system to actually persist data on
disk when you call flush(). Example [http://rhaas.blogspot.it/2014/03/linuxs-
fsync-woes-are-getti...](http://rhaas.blogspot.it/2014/03/linuxs-fsync-woes-
are-getting-some.html?m=1)

------
johnchristopher
I wish the author had included real life expectancy but that would take months
and multiple redundant set-ups.

~~~
geerlingguy
FWIW, I have had three of the cards in Pis running 24x7 with a sustained low
workload of writes (logging and server log files), one for www.pidramble.com,
and two for an internal data collection project, and have had no card issues
in that time. The cards I've tested < 6 months include the 300x Transcend, the
SanDisk Extreme, and the Kingston C10 (which may be slow, but is fine for
basic logging purposes).

~~~
johnchristopher
Thanks for the info :).

------
bcrack
This can become very useful, especially if expanded by others as well. If I
understand correctly results refer to raspberry Pi 2? They would probably be
similar for both rPi B+ and rPi 2 although it would be nice to mention the
model somewhere.

~~~
geerlingguy
Sometimes sustained reads/writes are a little slower due to RAM size and/or
processor speed, but the variations are minor.

------
rasz_pl
fast 4K random writes are nice, but you know what is nicer? Filesystem
designed for flash and OS tuned to NOT write randomly all the time. Pees
routinely corrupts root partitions and stop booting because system images are
not tuned for SD card usage, and EXT4 is terrible at being on flash.

~~~
dspillett
_> Pees routinely corrupts root partitions and stop booting because system
images are not tuned for SD card usage_

My two Pis (currently both just running as Kodi boxes, but I've played with
other things on them too) had a habit of killing SD cards, both cheaper ones
which might well just be the cheapness of the cards and the better ones
recommended by various people. I've taken to running them off NFS: the only
thing that stays on the SD card is a boot partition and boot sector. For
sequential reads this is definitely slower but they don't happen much (aside
from the video playing, but that is limited by desired playback speed not IO
bandwidth an happens over the network to my media array anyway), for
sequential write it should be too unless using a crap card, but when-ever I've
noticed a difference in responsiveness the NFS option has been faster. I find
it takes longer for them to boot, but once running everything is either the
same or feels just a little nippier.

This is not an option for disconnected (or unreliably connected) units of
course, and might be a chunk more faf to manage via wireless, but I recommend
it for units that always have a wired connection to the local LAN where said
LAN has an always-on machine capable of serving via NFS.

~~~
sangnoir
Check the amperage of your power-supply. I had the same problem when I had a
questionable power supply that was providing insufficient juice. I must have
gone through 4 SD cards - the problem went away when I switched to a 2-amp
transformer/adaptor.

Another thing you might want to check is how well ventilated your Pi is, high
temperatures might also toast cards.

~~~
geerlingguy
This. Almost every time I've had any corruption problems, it was preceded by
the little under-voltage rainbow icon appearing. Also, if you have things
plugged into USB, consider setting the usb_max_current setting to 1 in
/boot/config.txt

~~~
Albright
What is the "under-voltage rainbow icon?" Is that on the Pi itself, or in some
program?

~~~
cnvogel
[http://i.imgur.com/673Qw1i.jpg](http://i.imgur.com/673Qw1i.jpg)

As far as I know there's a task running on the "GPU" (where quite a few things
are assisting the ARM CPU showing the screen, playing audio, actually
bootstrapping the ARM, ...) that provides this icon as a feedback to the user.

~~~
Albright
Ah, hmm. So I guess you don't see it if you're using it headlessly… that's
mostly how I've tinkered with my Pi.

------
odabaxok
Here is another list:

[http://elinux.org/RPi_SD_cards#SD_card_performance](http://elinux.org/RPi_SD_cards#SD_card_performance)

~~~
geerlingguy
That listing doesn't give any indication of small-file performance, so for my
usage, it's near worthless. If you deal with media files mostly, it's plenty
helpful, but for most things I use the Pi for, 4K read/write is the most
important statistic.

------
guylepage3
Thank you for putting this together. Great work

~~~
electricblue
Yeah I was just looking for something like this for my Pi 2 so thanks!

------
logicallee
I'm surprised the data is elided for the last row, seems it would be the most
interesting.

At any rate 0.17 MB/sec (Kingston C10) 4k random write vs 8.2 MB/sec (OWC) is
a staggering 48x speed difference. That is like the difference between 1 Ghz
and 20 Mhz. Very useful and interesting comparison.

~~~
geerlingguy
All those numbers were under 0.1 MB/sec, and I gave up on the 4K tests after
they were running a couple hours. Excruciating!

~~~
logicallee
write that! :) ( "< 0.1 MB/sec"). Though I wonder if that isn't some faulty
issue.

~~~
geerlingguy
It's not faulty; I've tried with a couple super-cheap/no-name cards, and
they're all insanely slow (even a few class 6 or class 10 cards).

Reading up on the flash industry, it looks like most manufacturers use flash
from one or two main producers, and each smaller company uses the
discarded/slower/cheapest parts, resulting in worse performance and
reliability in the lowest rungs of the scale.

[Edit: I've also updated the numbers in the post]

~~~
logicallee
this is much bigger news than the comparison among real cards. These cards
should not be sold - 100x slower isn't "working" for the same value of
working. Your scale goes to 800x slower. that is the difference between a
Ferrari (217 MPH or 350 KPH) and 0.27 MPH or 0.31 KPH. Walking speed is 3-4
MPH. So it's the difference between the fastest Ferrari... and less than
1/10th walking speed. It's the difference between the max speed of the fastest
Ferraris, and literally scooting along on the floor, on your butt.

That is much, much bigger news than the rest of your benchmark. These are
faulty and unusable, by the same benchmark. Imagine if someone has one in
their pi.

I appreciate you running these benchmarks, by the way.

------
mschuster91
The Pi does have an eMMC interface, as evidenced by the Compute Module. Wonder
why there's no, let's say, $45 option with eMMC available...

~~~
TD-Linux
Well, from a development perspective a SD card is a lot nicer because you can
pop it out and write it easily if you brick it, whereas eMMC requires fastboot
or weird OEM loaders that only run on 32 bit XP on Tuesdays.

Also, eMMC's bus can reach higher speeds than SDHC, but that is only useful if
you get an expensive and fast eMMC. I have used embedded boards where the eMMC
was slower than a Sandisk Ultra microSD card.

~~~
mschuster91
Add u-boot with tftp flashing. u-boot already works on the Pi, and since my
latest patches even with proper FDT/ATAG pass-through.

------
thearn4
I have a couple of Pis running at home. To be honest, I've had enough SD card
corruptions across a variety of models that I've moved to running the root
directory off of USB. Has anyone else experienced this, or is this likely
closely tied to my use case?

~~~
geerlingguy
It could be related to your power supply, honestly. I haven't had more than
one or two corruptions in the time I've been using my Pis, and both seemed to
be related to cheap/flaky power adapters.

------
post_break
Needs the Lexar 633x and 1000x on there for testing.

------
geerlingguy
Unrelated aside: I submitted this story yesterday... How is it only now
showing up as '1 hour ago' as of midnight a day later?

~~~
Tomte
HN is auto-reposting some stories that its selection algorithm sees as
valuable, but that didn't get attention.

There is also another variant: dang is sometimes sending out special links to
repost stories that were manually vetted as good, but ignored. Those get
special treatment, for example, they cannot be flagged down (easily at least,
maybe at all).

~~~
dang
We're sending fewer of those emails now because a lot of users don't like the
repost aspect. But we still do send some, e.g. if the post is older than a day
or two, or if it's a Show HN and we want to make sure the submitter is aware
that the story may get a discussion after all.

~~~
shasheene
I'm not really comfortable with the alteration of timestamps. Much prefer they
reflect reality.

Pushing a new timestamp to a list for every edit/resubmission makes me more
comfortable, and keeps the immutability aspect (a trustable record of
history).

I'd also prefer being able to see the full edit history of comments, so assign
weights to my views accordingly (a grain of salt).

~~~
dang
I completely understand. In fact we expected to hear this from a lot more
users. But if the feedback we see is representative, people care a lot more
about not having duplicates.

I should add, for anyone who hasn't read the post I linked to above, that the
original timestamp is always available from the user's /submitted list (linked
to from their profile) and the /from list for the site (linked to from the
domain name in the title line for a story). The relative (re-upped) timestamp
is only shown on the front page and the /item page. Over time, the two
converge, since the re-upped submissions to date have all been recent, i.e.
less than a day or two old.

The intention is definitely not to make the original timestamp (or any other
information) unavailable, and we'd be happy to hear suggestions for how to
handle it differently.

Showing the history of comment edits is another matter. Sometimes people post
things that they shouldn't post, and it seems decent to give them a way out by
deleting the comment or editing out the sensitive or egregious bit. I think
that's a fair privilege to trust users with—it's part of having a real
community and good conversation, and although a few do abuse it, it really is
surprisingly few. Except for a few perfect souls, we all blurt out things we
shouldn't, so we all benefit from this. And we'd hate for bad real-life things
to happen to people over what they post here.

~~~
ethbro
Just wanted to say thanks for the continued tweaks! Use and metrics are great,
but here's a +1 human comment on the effort put into improving things for
everyone.

