Raspberry Pi microSD card performance comparison | Hacker News Reader

Raspberry Pi microSD card performance comparison

jeffgeerling.com

129 pointsgeerlingguy66 comments

I wouldn't buy an sd card on amazon because of the risk of getting a fake. There are tons of fake sd cards out there and amazon refuses to take responsibility for their supply chain.

Where do you buy SD cards?

DigiKey

MicroCenter.

They price match Amazon, NewEgg, B&H, and lots of other places. A lot of times their prices are already lower than Amazon.

Sandisk cards for domestic sale in China have 18-digit authenticity code on scratchpad, and you can verify it online at verify.sandisk.cn.

So, "buy in China because there's too many fakes in US store". Ironic isn't it.

I came here to say the same. :) I can attest that this works. I've checked these codes on several cards along with speed and full rewrite/compare tests, to verify capacity and A1 rating.

Never had an issue.

I've checked a couple of fake Sundisk cards from Aliexpress as well, detected as fake as they should.

I'm sure there's a name for this effect, but I am always fascinated by the complaints about fake products on Amazon. I have _never_ received one and I spend several thousand on Amazon every year.

I _know_ it must be happening, I just can't understand if I'm lucky, if it's an effect of my location, or somehow related to the way in which I shop on Amazon.

Many of the major product listings seem to be okay—for example I've ordered a number of the Samsung Evo+ cards I link to in the blog post, and tested each one and never found one that didn't perform as the first I bought—but I have gotten fakes here and there.

Almost every time, though, it's because the Amazon official supplier/warehouse was out of stock and I accidentally ordered from one of the secondary suppliers. The problem is, unless you know what to look for in the interface, it's hard to determine if you're buying from Amazon or the manufacturer, or some 3rd party.

Even then, there are many reputable 3rd parties. But there are many who are not.

The worst cases in my experience are ordering 'Apple OEM' type products. I will not buy a charger or any other Apple accessory on Amazon because more than 50% of the time I've gotten a non-Apple-manufactured product.

> The problem is, unless you know what to look for in the interface, it's hard to determine if you're buying from Amazon or the manufacturer, or some 3rd party.

Also, Amazon sometimes commingles their own stock with that of 3rd-party vendors, so "Ships and Sold by Amazon" doesn't mean what it used to.

EDIT: fixed numerous typos >:(

> I have _never_ received one

That you know of.

My take is that a 'fake' that's actually identical in terms of function is real enough for me (these could be ghost-shift output from the same factories, for example). The horror stories you see about SD cards though are unusable things that pretend to have huge capacity but won't hold data etc. so those are truly fakes.

I believe a lot of it can be attributed to shopping behavior. For instance I personally never "Sort by: Price: Low to High"; you are almost guaranteed to end up with a fake product at the top. What's more subtle is that when I watch other people (as part of a group project) order stuff on Amazon they seem to not pick up clues about the quality of the product. They purely focus on title, picture and of course price.

Haven't had any issues. Plus on top of that I mostly buy warehouse deals - i.e. open box/returns.

I've never had a fake SD card that was sold by Amazon.

At least in Amazon US, they comingle Amazon inventory with other FBA sellers, so even sold by Amazon isn't a guarantee.

Wirecutter claims that the Evo Select line is an Amazon exclusive rebranding of the Evo Plus line and that this should reduce concern about getting a fake - for that line at least. https://thewirecutter.com/reviews/best-microsd-card/

I wonder if Pi 4 supports UASP (USB Attached SCSI Protocol). This may need everything from the VLI VL805-06 USB controller to the firmware to the driver to support it. A preliminary DDG search suggests that the controller probably supports it.

My understanding is that, if UASP is supported, you can squeeze even more performance out of a SSD, and it will even properly support the TRIM command because then the SSD is no longer just a dumb USB mass storage device.

This would be interesting to check; I know there are few people on the Pi forums exploring some of the outer edges of what's now possible with a decent USB controller.

TRIM is supported by USB mass storage devices since those are _also_ SCSI. It is the bridges that may not support it, and the same is true for USB-attached SCSI.

For USB-attached SCSI, what makes a difference in performance is support for USB 3.0 streams, which allow multiple transfers to occur concurrently (https://www.kernel.org/doc/html/latest/driver-api/usb/bulk-s...).

Ah. I didn't know that USB mass storage is also SCSI. Is TRIM/UNMAP part of the SCSI Transparent Command Set, which depends on the SCSI Peripheral Device Type reported (by the USB-SATA bridge?) in response to INQUIRY?

What exactly is the "SCSI Transparent Command Set" anyway? I haven't been able to find an answer from DuckDuckGo search. The Wikipedia article on USB Mass Storage [1] mentions it, but doesn't really define it. Neither does the article on the SCSI command [2] itself.

Another post [3] touches upon SCSI Transparent Command Set, but also says in passing that the SCSI specifications at t10.org don't mention the "SCSI Transparent Command Set".

[1] https://en.wikipedia.org/wiki/USB_mass_storage_device_class#...

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

[3] http://janaxelson.com/mass_storage_faq.htm

Note to readers: The USB chip does run hot. This is getting fixed in a firmware update that you can test in the RPF Forum which reduces temps.

I wonder if that's the reason for somewhat patchy USB performance. when copying data between two USB HDDs the data goes at 40-50MB/s for a minute or two then drops down to like 500kb/s and then ramps up again after a while. When copying data the USB chip and the ports themselves get stupidly hot.

Yeah... it surprised me that the VLI USB chip was much hotter than the processor even during CPU stress testing. Between that and the little power controller chip by the USB-C power supply port, the Pi 4 pretty much demands active cooling for any but the most mundane tasks.

Once upon a time, Linaro produced flashbench, a tool for learning more information about how managed NAND devices (mmc, sdcard, etc) actually manage their flash. LWN did a story on some of their conclusions [1]. One of the standouts for me was that some erase blocks are managed completely differently from others, such that random i/o performance can vary based on the location on the device. Traditional filesystem benchmarks aren't set up to observe this behavior.

IIUC, F2FS incorporated some of that information, and not much else has. But in principle, you should manage your device with short extents and inode tables in the small-block-friendly area, and larger extents elsewhere whenever possible.

[0]: https://github.com/bradfa/flashbench [1]: https://lwn.net/Articles/428584/

I now only use "Endurance" microSD cards, which I think are supposed to be for dashcams, in my Pi's, because I've never not had a normal microSD card ultimately be killed by the Pi through what I assume is write endurance exhaustion.

Did they die pretty early on? Do you use USB port on a hub/PC/etc for power?

If answers to both of those questions are YES, over the years in reading forums/comments/etc a common thread between them has been that rPi kills microSD cards, and the commonality between most of those posts has been the use of (low/unstable) power strictly off of a USB port of another device (instead of a wall adapter)

Edit: I now see that geerlingguy addresses this elsewhere in the thread too, so he can add at least some anecedotal experience that drawing too much power from a poorly-powered rPi is a recipe for failed SD cards

(Sorry if this is completely irrelevant- it may just be that if you write to your cards a lot they're dying from that due to endurance, like you said)

I generally use a dedicated USB power supply so that should not be the problem. And I haven't yet had an "endurance" card die.

Not Pi, but related - I gave up on using a 64GB Kingston SDXC in a Lexar reader to play MP3s in my truck. After just a few days it would develop corruption at the end of songs and by a few weeks it was just too annoying to continue using.

I looked at some of the files and it appeared to be a bit flip type problem. Went to a dedicated usb thumbdrive (as has been in my car's glovebox for 7 years) and no issues. Really makes me question using these sdxc cards at all.

I know embedded systems were not the original purpose of the Raspberry Pi, but so many people are trying to use the pi for just that. I've wanted to use Rpi for that but the SD card failure rates are high. I know the high-end ones are a lot lower, but is it reliable enough? I am not sure. I was hopping for a SD card alternative for the Rpi 4, maybe it's booting from USB 3.0 when that ships?

You can get “industrial” SD cards that are rated for more severe environmental conditions and more write cycles. They are more expensive though, but probably worth it for commercial applications.

You can also get "Endurance" SD cards. A lot of failures are due to too many writes. The endurance ones allow many more writes than the regular consumer cards

The 'industrial' microSD cards based on MLC or pSLC with controlled or frozen BoM only make sense if you are going to use a device in extreme settings[1]. In most instances, a card in rPi will serve as a boot device, unless someone reappropriates it into a Dashcam or something similar, which has heavy duty write cycles or continuously reads/writes to and from the card; it will be wise to choose something that strikes a balance.

At a guess, the Samsung EVO family of consumer based cards, probably ranges between using TLC (older) to 2D or 3D V-NAND (newer). The more robust Pro series, which commands a premium, probably uses MLC or superior.[2]

[1] https://www.swissbit.com/products/nand-flash-products/micros...

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

That's blatantly not true, as I've run into controller issues from verified authentic name brand cards. A 80kbyte/sec write with a specific pattern for about six hours would absolutely hose the card (and yes the card was write leveling).

There's so much nice about the industrial cards that have nothing to do with it's ability to endure extreme environments, that I would basically never ship a non consumer product without them at this point.

> A 80kbyte/sec write with a specific pattern for about six hours would absolutely hose the card (and yes the card was write leveling).

80kB/s sounds a bit low for a card that is doing full "global" wear leveling; memory cards and SSDs that don't have DRAM often cut corners on the wear leveling, so they aren't as effective as proper mainstream SSDs. Your workload was probably issuing the writes in chunks smaller than the flash memory's page size (typically 16kB these days), so you probably had serious write amplification from the read-modify-write cycles even if that 80kB/s was sequential writes. SSDs with decent-sized write buffers and power loss protection capacitors can do more write combining than a memory card that has to be prepared for sudden power loss at any moment.

Yeah, it is very low, which is why I bring it up. It was a controller bug, where the FTL completely lost track of some sectors. Write amplification has nothing to do with it.

Well you’d better add “unexpected power loss” to your “extreme settings” category. Loads of cards have problems with that. I’ve experienced multiple SD card corruption events upon power loss with the Rpi until I started buying industrial cards.

Had good luck with the ones mentioned in https://news.ycombinator.com/item?id=16777238

It would not be feasible to list every extreme event or permutations thereof, but any kind of power loss would be an undesirable event. Perhaps, it is not clear from my comment, I added a caveat to distinguish between hobbyist or commercial use i.e. in majority of former cases, it might be feasible to find a compromise between price, stability and endurance [0][1].

Further to your link, my experience with Samsung Pro series has been very favourable. YMMV.

[0] https://www.raspberrypi.org/forums/viewtopic.php?t=184696

[1] https://www.tomshardware.co.uk/raspberry-pi-4-ssd-test,news-...

It happens a lot, unfortunately, for multiple reasons. First is ordinary power loss, then the fact that Rpi comes with no power button so people get impatient and yank the power (ok, that’s not unexpected, but corruption is), and then Rpis have long been known to be finicky with their power requirements. In the latter case, I've seen it happen from a too-long USB power cable.

One can argue about whether those reasons are in the "but the user should know better" column, but when they result in a corrupted filesystem, they nevertheless add up to a poor user experience.

Hope one day the Rpi has easygoing power requirements and a button you can push for orderly shutdown.

I hear this every year when I post new benchmark results, but it's weird, I have literally not had one microSD card failure when using any of SanDisk, Samsung, or Sony.

I had one fail with a Toshiba card, but at that time I was also using a cheap micro USB power adapter that probably wasn't putting out a solid 2A.

I think the primary reason people have problems with microSD card corruption is the power supply. Even with a good power supply, when you plug in a lot of USB devices and push a Pi to the limits, it can draw ~2+ Amps, and only very good power supplies will not have weird issues at that draw.

The Pi doesn't handle that situation very well (nor do microSD cards).

But running my Pis headless (no USB accessories attached) without any video output keeps the power draw down to 1-1.5A max, even when CPUs are maxed out and I'm saturating the network.

I've had much better luck using aMLC and pSLC cards than generic TLC ones. I would expect "industrial" MLC/SLC to be even better. There was an enlightening discussion on HN about them at https://news.ycombinator.com/item?id=16776344

You can also reduce risks with your choice of filesystem, read-only partitions, and FS tuning/alignment. I wrote up my findings after looking into it last year: https://kevinlocke.name/bits/2018/04/28/rpi-sd-card-storage-...

really, what the pi needs is rpi-config to support an option for a read-only root filesystem with an overlay filesystem.

For example, this is the standard configuration for openwrt (which you can run on the pi)

That’s not a panacea. Power loss can still get you: https://news.ycombinator.com/item?id=16777889

My first time creating s pihole I had everything setup with a nice sd card then proceeded to put this plastic case over it. Seemed a little tough to put on like it was a little pressure fit so I clicked it into place then tried starting it back up. Well it never came up then I started looking at the pi and realized that the case didn’t have a cutout where the sd card protrudes and it cracked the damn card at the tip! Ended up using a cheaper one I had lying around but wow, lesson learned the hard way.

I'm a big fan of the RPI, and use them in various home projects, but I'm going to continue to wait out the RPI updates until I can get a proper m.2 slot for a "real" hard drive. Working with SD -- especially when continually developing, is just too slow and painful. Not to mention questions about lifetime and lifecycle.

The price of m.2 drives have come down so significantly that I think SD should be slowly phased out, or added as a secondary option.

There are a few ways to do this now:

m.2 add-on boards, such as https://amzn.com/B01NH2W8NL

boot directly from a good usb flash drive (I like the sandisk cz80, though they seem scarce now)

Soon rPi4 will support directly booting from USB3.0 - a USB flash drive (or preferably, SSD) would be a good middle-ground instead of waiting for m.2

Is there really a need for random 4K writes on the SD card in the Pi? Couldn’t the card use a log-structured filesystem and batch writes in RAM, turning those writes into streaming writes? The new Pi certainly has enough RAM that it could dedicate some to serving as a write cache.

This is the choice that lots of system designers have to make, "low apparent write latency" vs "maximum data at risk of power loss". If there's a database on the Pi you're going to be upset if you call fsync() and it doesn't actually do the writes.

if you have implemented fsync() to not sync to actual backing storage you have a bug in your design. That is orthogonal to caching the writes in RAM prior.

Sure, but for this use case if you're doing a set of database transactions each will be its own write to persistent storage. Which is why you care about the random 4k write speed.

"Sequential writes are much faster than random writes" is not at all a new problem, it dates from the hard disk era. Which is why most filesystems will cache as much as they think they can get away with.

When I do OS updates (Fedora, so that's dnf and rpm) with a system on USB flash or SD Card flash, the write are abysmal. Like, 3-4MB/s, using `iotop -d3 -o`. There's almost no reads suggesting the RPMs that have been downloaded are cached. I experience this with ext4, btrfs, and f2fs.

Using strace on both dnf and rpm, there's no appreciable amount of sync(), fsync(), or fdatasync() - so I'm not really sure why there was this persistent ~4MB/s trickle to the card rather than large "state" updates, in particular for f2fs and Btrfs. All three make heavy use of delayed allocation, but in particular f2fs and Btrfs have no specifically designated locations for write, or overwrites. So I'd expect that most update OS type writes should/could be much faster.

A sequential write is ~20MB/s on both of these media, and sequential reads are ~150MB/s. I wasn't ever able to profile it well enough to understand why it's so dog slow.

This is a false dichotomy. Most (all?) contemporary high-reliability (and, arguably, high performance) filesystems are long structured.

(I am excluding things such as ext4 that are missing data block checksumming, and recovery from disk failure using parity stripes)

>high-reliability (and, arguably, high performance) filesystems are long structured.

That prevents the filesystem from being in a inconsistent state, but doesn't address the issue of data loss. eg. what happens if there's 5M outstanding writes and you get a fysnc? If you wait for everything to be flushed, that's going to produce latency. If you lie and return immediately, and there's a power outage, you now lost those oustanding writes.

A decent FS will make sure there are never 5M outstanding writes that an unrelated fsync depends on.

If there's ever a way to avoid writing small chunks to disk, that's preferred. But I think people are spoiled by having fast SSDs in their local machines, and much of today's software, web applications, etc. expect to be able to treat SSDs as RAM, pretty much.

Once I can fully boot my Pis off USB, I'm planning on reworking my cluster to run off SSD alone to see what kind of performance I can get out of it.

tl;dr: the Pi 4 has a much more rosy outlook when it comes to IO both for the microSD card and external drives. The Samsung Evo+ is still the best value for your money.

It is not, it's pretty much equal to Sandisk Ultra A1 in performance. (not the same as the one tested in this test)

You can get original 32GB Sandisk Ultra A1 for $4.30 (or $8 incl. shipping) on aliexpress.

Evo+ is $8.60 (or $15.79 incl. shipping) on Amazon.

Do you trust a microSD card you've bought off Aliexpress? Because I wouldn't. It's questionable if you can even trust one purchased from Amazon, but buying off Aliexpress is next level skeezy. There are a vast amount of fake/counterfeit microSD cars on the marketplace, so this argument is pretty silly if you ask me.

See above.

https://news.ycombinator.com/item?id=20403155

I wouldn't write the comment if I wasn't 100% sure the cards were original. Yes, you can get original Sandisk cards from aliexpress for that price, and actually verify it on the manufacturer's website. You can't do that for Samsung.

Let me prefix saying I appreciated your writing. However you didn't test endurance. You only tested throughput (I/O). Throughput isn't the same as performance. Why call it performance?

I had Raspberry Pi's fail from consumer grade microSD cards. Which sucks if its ~4 hrs of travel (one way). This hasn't happened with industrial grade yet. (I buy mine from DigiKey.)

I'm curious about throughput differences with regards to filesystems.

Two ideas for a follow-up.

The 32GB card I have running in the Pi that often hosts www.pidramble.com has been running on a Pi 2, Pi 3, Pi 3 B+, and now Pi 4 for almost four years and has not had any corruption issues.

I also have had a number of other Pis using the Samsung Evo+ and SanDisk extreme cards, many running for one to two years (some doing logging, others saving time-lapse pictures, uploading in batch to an FTP share, then saving more), and have also never encountered a corruption.

I think it has a lot more to do with the power supply than the card itself (as long as you're using a SanDisk, Sony, Samsung, etc. and not some no-name card).

I think the endurance cards have a little better caching mechanism built into the flash controller itself, so they can kind of paper over flaky power supply issues. So yes, it is definitely better to use endurance class cards. But in my experience, I have not encountered an issue using the typical consumer-grade cards.

I'm surprised by the lack of mention of the A1/A2 "Application Performance Class"[1]. These classes specify minimum performance numbers for random reads and random writes: 1500/500 read/write for A1, 4000/2000 read/write for A2.

Notably, the Amazon link for the Sandisk Extreme points to an A1 version, not the A2 version[2]

  1. https://www.sdcard.org/developers/overview/application/index.html
  2. https://smile.amazon.com/gp/product/B07FCMBLV6

My understanding is that A2 cards are generally slower than A1 cards IF you don't have host-side support for managing the volatile-RAM caching that A2 requires.

So if the Pi 4 only allows you to run in A1 mode anyway, you're better off buying the A1 card and both saving money and getting a faster card. I don't know if that lack of support is true of the Pi 4, but it does seem to be true of most other SBCs according to https://github.com/ThomasKaiser/Knowledge/blob/master/articl...

Ah, interesting, I did not realize there was a difference in protocol. I thought A1/A2 were just spec requirements.

I wonder if A2 support is something that could be added in newer kernels, or whether it requires hardware support.

I've gone through three Samsung EVO sdcards in an Intel NUC. I was using it as a boot drive. All were replaced under warranty. But they each died, becoming read-only, within about 5 months of use.

I don't think these cards are designed as random access devices. I think they're for cameras: video and photos, and also for cell phones, also mostly video and photos, maybe some app offloading also.

Reply on news.ycombinator.com