Raspberry Pi microSD card performance comparison | Hacker News Reader

Raspberry Pi microSD card performance comparison

midwesternmac.com

180 pointsgeerlingguy57 comments

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.

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.

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

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.

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.

Thanks for the info :)

Why? SanDisk Extreme is faster except for 4K random writes, according to this table. I don't think 4K random writes matters much for most workloads you are going to put on a Raspberry PI.

You might be surprised about what does some random writes. Imagine you have a bunch of services which don't directly use the disk, but all log to some rotating log files. Or maybe every once in a while, something needs to fsync a random bunch of config files.

Yeah that's not so hard, but look again at just how slow random writes can be. An improvement in that (by far worst) statistic is often much more significant than a much larger improvement in linear read or write.

The only situation where I have found disk (SD) IO to be lacking on the RPI is when running apt-get install or upgrade. I have not run any services that generates a lot of log entries or random writes in general. Maybe it is because I don't think of the RPI as a small server but as an embedded development platform.

Try installing the wonderfully named 'eatmydata' package. Running 'eatmydata [command]' will execute the supplied command and will prevent it from syncing buffers to disk.

apt-get and dpkg call sync() and fsync() a lot to ensure file consistency in the event of power loss. This forces lots of tiny writes to disk. If you throw away the sync calls, the kernel can do a much better job of coalescing the writes into larger, contiguous I/O operations.

Now, obviously you are sacrificing reliability for speed here. You don't want to use 'eatmydata' with a long-running process as you are basically guaranteeing data loss. But for stuff like installing a new package on a system that is not going to suddenly lose power, it will speed things up surprisingly well.

But apt-get is exactly where you'd expect a ton of random rights.

I don't think so. The files are mostly going to be stored contiguously. There is of-cause the journal that is written, but it is not exactly what I would call random. I guess something like SystemTap could be used to determine this but I do not have the time right now.

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.

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.

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

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...

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)

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...

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

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).

Thanks for the info :).

A good project for a student group though. Ten RPis, ten cards, some scripts to read and write and delete data.

In somewhat similar test, it took almost 11.5 million writes over 3 weeks to burn though 2401 EEPROM chip. [1]

SD card case is both simpler: no need for custom hardware, and at the same time harder: there is flash translation layer [2] between RPi and actual flash erase-blocks, so write patterns, block size, etc. do affect lifetime.

[1] http://dangerousprototypes.com/2010/05/25/prototype-flash_de...

[2] https://en.wikipedia.org/wiki/Wear_leveling

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.

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

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.

One pro tip: if you're running a web server like Nginx or Apache, make sure you either disable all logging, or set logging to use a larger write cache so it will bundle up writes into larger (e.g. 32KB) chunks instead of flushing every line to disk immediately.

> 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.

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.

Thanks for the hints.

I did have trouble running a USB drive that worked everywhere else off them, so perhaps power is the problem and that not working was due to it being more hungry and other drives and the Pis not having enough amps spare to hand over.

This wasn't filesystem corruption though: the SD cards never worked properly again so there was presumably some physical issue rather than just damaged data. I can't say I've noticed any part of them being at all warm either in general running or after a card had died so if it is heat related the heat was temporary (and they aren't where things like direct sunlight or near-by household heating could be a variable).

I'll check the power supply at some point, but for now they've both been running smoothly 24/7 for months so I'm happy with the NFS solution for the time being.

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

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

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.

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.

Here is another list:

http://elinux.org/RPi_SD_cards#SD_card_performance

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.

Thank you for putting this together. Great work

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

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.

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!

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

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]

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.

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...

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.

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.

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?

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.

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

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

It's our latest experiment in giving good submissions a second chance at the front page. I've written about it at https://news.ycombinator.com/item?id=10537417 and in earlier posts linked from there.

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).

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.

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).

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.

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.

Thanks for this detail; it makes sense to me, and I do see the original time stamp in other listings, so that's helpful!

Reply on news.ycombinator.com