Raspberry Pi microSD card performance comparison

https://www.jeffgeerling.com/blog/2018/raspberry-pi-microsd-card-performance-comparison-2018

by geerlingguy • 8 years ago

270 125 8 years ago

jeffgeerling.com

TheForumTroll• 8 years ago

Interesting. I wonder how bad the other cards are in comparison to not warrant a test at all.

jzawodn• 8 years ago

Yeah, same here.

geerlingguy9• 8 years ago

See my post from 2015: https://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-p...

I re-tested a couple of the cards (notably, the Sony and Kingston cards), and they were just as painfully slow. The benchmarks took like 20 minutes (with the faster cards they only take 3-4 min).

If you use knockoff cards (no brand at all, like one that came with one of my cheap drones), the performance is so abysmally slow you might think the Pi locked up for a few hours.

kobayashi3• 8 years ago

Do you think that these top-tier cards are necessary for use in a Pi-Hole in an average home? Or is something like a Lexar card good enough?

jscheel• 8 years ago

I would just be happy if my rpi would not randomly corrupt the memory card for no reason all the time. Have it on a quality adapter, hooked up to a ups, with a quality card, yet it still corrupts itself for no reason.

kiddico• 8 years ago

Do you have an overclock running? Specifically sdram_freq.

penagwin2• 8 years ago

Also losing power seems to result in a corrupt sd card 80% of time.

Obviously it's bad to lose power while on, but that's crazy.

semi-extrinsic• 8 years ago

I had a GoPro develop a flaky voltage regulator so it would sometimes brown out, that thing killed microSD cards like a champ.

slig2• 8 years ago

Once corrupted, it can't be re-used after formatting?

monocasa11• 8 years ago

I worked on a project professionally to find out why we were corrupting SD cards. Turned out that the SD card firmware is just garbage in a lot of cases. Ended up with a test program that could corrupt an SD card from a given manufacturer within a couple hours with slow (80kb/s) continous reads and writes from any hardware running Linux. The manufacturer couldn't have cared less and essientially blew us off despite having a support contract.

Long story, short, buy 'industrial' SD cards if you care about them not getting corrupted.

Ahmed90• 8 years ago

Are you allowed to share the results of your experiment? i have a similar issue with a very limited market (SD Brands/models), it would be great if you provide more info :)

pera2• 8 years ago

Yeah, industrial grade SDs is the way to go. Here is an interesting graphic comparing different types of NAND memories:

https://www.cactus-tech.com/resources/blog/details/slc-pslc-...

more-coffee• 8 years ago

Been in a similar boat. Management said we couldn't afford industrial cards because it would kill the margin on the embedded devices they were used in, so we had to make it work with 3$ p.o.s. cards, which would corrupt after 6-12 months.

Ended up mounting /var on a tmpfs - ensuring practically no writes to the card - and fetching the device configuration from a server in the network at boot. PLenty of work, with zero (or negative) profit for the company, but at least I learned a thing or two doing it.

24gttghh• 8 years ago

Wow I had no idea to even look for different NAND geometries for SD cards! More expensive obviously but probably well worth it.

jpm_sd• 8 years ago

Yes, SD cards are garbage. eMMC is far, far superior.

StavrosK3• 8 years ago

Why not name the manufacturer so we can avoid them?

pingec• 8 years ago

Any recommendations?

rwky• 8 years ago

Any idea where industrial micro SD cards can be purchased in Europe? A casual search didn't yeild much info.

msumpter• 8 years ago

And that's why I moved over to MMC based Pi clones (specifically the Rock64), I am overly tired of SD cards mysteriously corrupting themselves. As of yet, I haven't had an MMC go upside down, but that's certainly far from guaranteed as well.

zwieback• 8 years ago

Do you know how much of that is due to connector and signal paths? I worked on a design that had soldered on eMMC and it was rock solid (and 8 bit wide) but I always assumed SD problems were due more to the flaky form factor. Is there a standard for removable eMMC modules?

copperx• 8 years ago

Is it possible for the rPi to boot from a USB device? One solution would be to hook it up to a $20 32GB SSD drive instead of relying on an SD card.

segmondy• 8 years ago

after how long? i've been running my pi off the usb port of my server. knock on wood, no issues yet.

geerlingguy9• 8 years ago

I've had a number of Pis (currently 6) in continuous operation around my house for over two years now. One is running http://www.drupalpi.com/ currently (uptime was 300+ days until last night when I re-flashed it)... I only use SanDisk Extreme and Samsung Evo+ cards now, but have not had any corruptions on any of these actively-used devices (most are either storing photos (e.g. time-lapse) and then dumping them to the cloud every week or month, or storing time-series data, so there are frequent writes.

I wonder if you could provide what type of card you're using? Also the type and brand of power supply? Besides any of the cheaper cards (basically any brand besides SanDisk and Samsung, it seems) being flaky in my experience, the power supply being flaky (usually when I used a cheap 500 mA supply that came with some device for free) is the only other thing that _ever_ caused corrupt data for me.

written4• 8 years ago

I have similar experience with SanDisk and Samsung EVO+. 9 Pi's (not raspberry) running continuously for ~2 years. No kernel panics/PostgreSQL failures. I run with data checksuming enabled. I also disabled options in PostgreSQL that cause periodic and unnecessary write activity.

Frequent regular updates, periodic database activity (web scraping, environment monitoring, ...). Running on F2FS.

I have logical replication setup in PostgreSQL, because I don't trust the SD cards anyway, but I have had no issues so far.

michrassena• 8 years ago

My first go around with the original Pi, I ended up burning out two micro SD cards in short order. The solution at the time was to mount the file systems read-only and put /tmp in RAM and do without swap (if I recall correctly). For my purposes this worked out fine, since the Pi was being used as a signage kiosk. Later I retired the original Pi and bought the series 3. I bought a much higher quality card, based on a similar performance and longevity article. Maybe something changed between versions of Pi, or maybe these cards really are better, but I haven't had the problem reoccur even with a read/write filesystem.

bscphil2• 8 years ago

I recommend netbooting the Pi off a server. Not only is it easy to back up and restore, the performance on small reads and writes is probably better than you can expect from any mSD card, if the specs here are to be believed. Plus you don't burn out SD cards that cost at least half what the Pi does.

geerlingguy9• 8 years ago

And as a bonus the Pi 3 B+ gets ~230 Mbps over LAN (whereas all the older models maxed out at ~93 Mbps), so netboot performance should be even better than in the past.

StavrosK3• 8 years ago

Are there any good guides on how to do this? I never once got it working. Also, where do you persist data? NFS share?

hazeii2• 8 years ago

Absolutely the way to go. We run loads of Pi's like this; older ones with an RO SD card holding the boot (so never get corrupted), later ones using the built-in PXE loader. Excellent for development as well; never be scared of doing a hard reset or Magic-Sysreq (this goes for PC's as well as Pis).

It's unfortunate that the built-in watchdog doesn't work during boot and shutdown, so a hang at these points won't be recovered without cycling the power. This can be addressed with an actual hardware watchdog connected to the P6 header (so if it's not being poked every so often, it does a cold boot).

The main issue for most home users is DHCP; normally the router provides DHCP and a lot of them are not compliant with the spec (making it tricky to set up a second DHCP just for netbooting). The solutions I know are using a separate network, or running your own DHCP for everything (my preferred solution).

fulafel• 8 years ago

You have to put absolute trust in the network in this scenario, not really acceptable architecture in 2018.

doctoboggan• 8 years ago

I built a product with an embedded rpi and dealt with this same problem. The solution was to purchase "industrial" SD cards. I ended up using ATP micro SD cards. You can find them on Digikey. They are almost double the price, but I have not had a single SD corruption since switching to them.

In my experience the samsung SD cards would be corrupted when the power was pulled around 30% of the time.

elijahparker• 8 years ago

I don't know if it's an issue with the rpi or not, but I know that SD cards can draw current in short spikes during writes and need a good supply with good decoupling capacitors so there's not voltage drops, as these can cause corruption. In an embedded device I've designed (with careful capacitor selection), I've very rarely had any SD card issues (3 corruption cases in ~1000 devices over a couple years). I'm using Sandisk and Samsung class 4, 6 or 10 (depending on availability).

Abishek_Muthian• 8 years ago

My overclocked pi's & abruptly shutdown pi's were the primary reason for my corrupted SD cards.

In my experience Toshiba Exceria M302 (built for action cameras) scores higher in longevity than Samsung EVO. I've abused the Toshiba SD card to get it corrupted & I've yet to see one.

mv4• 8 years ago

looks like that NOOBS card doesn't perform well at all

geerlingguy9• 8 years ago

It's better than the no-name cards, and even slightly faster than some of the secondary-brand cards (Transcend, PNY, Sony, Kingston, Toshiba).

It's not a terrible choice for a starter card, but you can get the Evo+ cheaper for the same capacity, if you can stand to flash it yourself :)

rmu09• 8 years ago

I got 3 Samsung EVOs (from 2015 or so) that got stuck in a kind of "read only" mode after some months in the Pi. All seems normal for some time, but writes are not persisted. After some time linux gets confused and panics. After rebooting, FS is always in exact same state.

makomk2• 8 years ago

I had a cheap off-brand Chinese SD card do that a while back. Was very confusing. Surprised that reputable brands do the same thing though.

cmurf3• 8 years ago

Same. I have a 32G Samsung EVO+ I use in a NUC with Linux that just went "read only" this week. 10 year warranty, and it's already setup for warranty replacement, which is sorta hilarious seeing as it cost $12, including the adapter (which itself is only warrantied for 1 year). I got 360 days out of the card, non-continuous use. But also interesting, they want the bad card returned to them - they're including a prepaid return shipping label.

The usage was just as a boot drive no user data: EFI FAT, ext4 /boot, Btrfs / using zstd and ssd_spread as the mount options.

FAT will mount ro or rw, but any writes fail

    [140718.615921] print_req_error: I/O error, dev mmcblk0, sector 2048
    [140718.615998] Buffer I/O error on dev mmcblk0p1, logical block 0, lost sync page write

Ext4 is similar but a lot more complaints from the mmc block driver, including an SDHCI REGISTER DUMP [1] which I can't make heads or tails of, but this is somewhat more revealing:

    [142132.340226] f28s.local kernel: mmc0: Card stuck in wrong state! mmcblk0 card_busy_detect status: 0xf00

Btrfs also has lots of complaints [2] but mainly because it never gives up trying to write. So cancel that and mount with '-o ro,norecovery' and everything is there. One thing you'll see in the Btrfs output, is "corrupt 10" which is not a current event, just a counter that I never reset. A few months ago I did have a data file (not fs metadata) become corrupt which Btrfs caught. I was able to reinstall the RPM that provided that file. So who knows how that corruption would manifest without being caught by the file system.

The blkdiscard command succeeds without error, but also doesn't actually do anything, all data is still there.

[1] https://drive.google.com/open?id=1Lbypuut21PreXnzHj9uC0x6lxK...

[2] https://drive.google.com/open?id=1340GQN29j8Ougtj_E0ey3A_RUJ...

written4• 8 years ago

Sounds too cheap, are you sure it's not a fake?

thebeardedone• 8 years ago

I have been victim of 3 evos myself, i didnt get very far into the configuration process (db, transmission, etc) before them more or less being rendered useless. The ssd evos are great but the sd cards are simply horrible, tragically I saw them locally bundled with pi starter kits. I ended up buying a sandisk which has not had a single hiccup even after a little bit of abuse.

tischler• 8 years ago

Why is that significantly slower than the specs of these SD cards (100-80 MB/s read/write)?

written4• 8 years ago

Host side interface limitation.

bluedino• 8 years ago

I'm sure the interface is slower than what you would find in a laptop, but I'm sure the blocksize of 4k/8k isn't helping on those tests.

geerlingguy9• 8 years ago

As @written says, there is a huge limitation on the microSD card reader on the Pi itself; but also, in my testing on a UHS-II USB 3.0 card reader on my MacBook Pro, most of the cards can't sustain more than 30-40 MB/s write even if the specs say they can.

Large block read speeds are usually pretty accurate, but manufacturers take quite a bit of liberty with their performance claims. And random I/O is pretty terrible in almost every case.

Remember that these types of cards are _usually_ optimized for large file I/O since they're used in dashcams, GoPros, and the like—use cases that are vastly different from a general computing device running Linux!

itakedrugs• 8 years ago

The RPi is more then likely the limiting factor... kind of makes the tests useless if you want to figure out which cards are faster

geerlingguy9• 8 years ago

The fastest cards in these tests were also fastest when writing the entire image on my USB 3.0 UHS-II card reader on my Mac. Large file writes are where most of these cards shine, and some can do 40+ MB/s when writing larger blocks of data.

khedoros13• 8 years ago

If I'm remembering correctly, the Pi's SD reader runs at 50MHz, doing 4-bit transfers, and not using any of the UHS signaling methods, because those use 1.8V signals that the Pi isn't set up to use for SD.

kind of makes the tests useless if you want to figure out which cards are faster

But...which card is faster in a USB3 UHS-III transfer isn't useful information for a Raspberry Pi benchmark. It would certainly tell you which cards are faster, but the info wouldn't be directly applicable to what the tests are trying to measure.

VMG• 8 years ago

wondering if I should just mount my external spinning platter hdd as root instead

mobilemidget• 8 years ago

Nice test!

Perhaps nice to add comparison to network storage/boot?

kobayashi3• 8 years ago

Has anyone found there to be a noticeable difference between a Lexar (or the like) and a Samsung Evo+ when using a Pi-Hole?

geerlingguy9• 8 years ago

When using Pi-Hole, the difference isn't that great. It's more network-latency-constrained (and maybe CPU) than anything else. But the difference is so small in my testing with Pi-Hole that I don't think it's worth worrying about _too_ much. For many other use cases, there would be a very large performance delta!

kobayashi3• 8 years ago

Thanks very much — both for this reply and for all your write-ups!

rubatuga2• 8 years ago

Is raspberry pi trapped in its own architecture? The Broadcom SOC chosen 5 years ago may have seemed like a good choice then, but the raspberry pi foundation is now facing an uphill battle since Broadcom doesn’t seem to be providing any significant updates to the raspberry pi, other than clock increases. You have the whole codebase based around this one chip, and I worry that this will mean painful migrations if raspberry pi ever switches to a new architecture

duskwuff2• 8 years ago

Er... what? The SoC has received multiple major updates. The Pi 3+ has a a quad-core, 64-bit SoC -- it's the same SoC family as the one in the original Pi, but a rather different CPU core.

rubatuga2• 8 years ago

Okay, sure. They changed the arm core. But the IO, the single USB port (internal), the video core, the lack of sata, poor SD card speed, these all remain.

gitgreen2• 8 years ago

Yup. The Pi has been based on ARMv8 architecture since late 2016, the same architecture that the latest Apple mobile chip(A11) is based on. There's plenty of room to grow in the Broadcom line. The only part that really needs attention is the bundled GPU which IIRC has never been updated since the RPi has been introduced.

amatecha• 8 years ago

Isn't the Pi3+ the same processor as the Pi3, just overclocked?

bullen2• 8 years ago

Thanks for finally finding the search terms I needed to discover this: https://www.digikey.com/product-detail/en/panasonic-electron...

Looks like my RPi 2 cluster is getting an upgrade!

bullen2• 8 years ago

Hold your horses, this is better:

https://www.digikey.com/product-detail/en/panasonic-electron...

and

http://eshop.sintech.cn/sdhcsd-card-to-micro-sd-tf-extender-...

http://www.saikosystems.com/web/p-44-sd-to-microsd-converter...

Depending on your location.

amq• 8 years ago

Would be also interesting to compare power consumption. Different microSD cards can range from 0.06 to 1.34+ mA in idle, which can be more than a microcontroller like ARM M4: https://electronics.stackexchange.com/a/123386

hyperpallium• 8 years ago

Is this also applicable for androids?

I got a cheapie sdcard, which slowed my phone noticeably. On amazon, reviewers say (as here) that random RW are the key metric, and (at that time), the sandisk sdcards were the best.

khedoros13• 8 years ago

Android phones use the SD card in a more computer-like way than a camera-like way, so random rw is important. There's actually an "app" rating introduced in the last year or two, but I think most manufacturers haven't bothered to get their cards certified yet. But some Sandisk cards now have an "A1" or "A2" marking on them, which represents application performance.

wemdyjreichert• 8 years ago

This feels like an LTT video.

ChuckMcM• 8 years ago

This was a good comment from the author --

"I've tested the ODROID-C2, Orange Pi, and am finishing up testing on the ASUS Tinker Board, and all of these boards are leagues beyond the Pi in terms of I/O performance (both networking and local storage). The problem is most of these boards are either priced the same as or more than the Pi 3 B+, and have a much worse initial onboarding experience (grabbing a disk image, flashing the card or onboard memory, first boot, then figuring out where to go next) than what you get with the Pi and it's handy, well-written tutorials."

That is the only reason that the Raspberry Pi maintains its position of where it is. It isn't a great computer, it is a great ecosystem. So often when I talk to people about my efforts in that space I get the "but my computer is so much faster than that" and I just nod. When the environment is the same on all machines (like it has been in the WinTel era) then its all about the specs of the machine. But when the environments are all different, its all about the environment.

digi_owl2• 8 years ago

Indeed. I can grab RPi and accessories virtually at the local mall (or at least i keep seeing ads for them from various store chains).

ODROID? Forget about it, has to order from abroad. Tinker Board, not sure. I think i have seen one specialist online store offer up the Orange PI.

jokoon• 8 years ago

The debian on rpi should not have its swap on the sd card, clear and simple.

A solution would be to have some filesystem on ram, and write new changes/deltas to the SD card either periodically, or at shutdown.

Raspberry Pi microSD card performance comparison

Related Stories