9 ms·

Raspberry Pi microSD card performance comparison

180 points by geerlingguy 11y ago

geerlingguy 11y ago
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 11y ago
  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 11y ago
    Sorry about that; all are 16GB except the 32GB Evo+, and 8GB Kingston and SanDisk Extreme Pro.
    - Nursie 11y ago
      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 11y ago
        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 11y ago
        Thanks for the info :)
- mortenlarsen 11y ago
  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.
  - ploxiln 11y ago
    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.
    - mortenlarsen 11y ago
      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.
      - reitzensteinm 11y ago
        But apt-get is exactly where you'd expect a ton of random rights.
        mortenlarsen 11y ago
        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.
      - joosters 11y ago
        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.
geerlingguy 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        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.
bcrack 11y ago
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 11y ago
  Sometimes sustained reads/writes are a little slower due to RAM size and/or processor speed, but the variations are minor.
odabaxok 11y ago
Here is another list: http://elinux.org/RPi_SD_cards#SD_card_performance http://elinux.org/RPi_SD_cards#SD_card_performance
- geerlingguy 11y ago
  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.
logicallee 11y ago
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 11y ago
  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 11y ago
    write that! :) ( "< 0.1 MB/sec"). Though I wonder if that isn't some faulty issue.
    - geerlingguy 11y ago
      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 11y ago
        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.
rasz_pl 11y ago
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 11y ago
  > 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 11y ago
    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 11y ago
      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
mschuster91 11y ago
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 11y ago
  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 11y ago
    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.
fulafel 11y ago
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 11y ago
  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 11y ago
    If your PG setup leaves writes sitting in the buffer cache after transaction commits, it's not working right.
    - pmontra 11y ago
      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-postgresql-for-large-amounts-of-ram http://dba.stackexchange.com/questions/18484/tuning-postgres...
      - fulafel 11y ago
        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)
johnchristopher 11y ago
I wish the author had included real life expectancy but that would take months and multiple redundant set-ups.
- DanBC 11y ago
  A good project for a student group though. Ten RPis, ten cards, some scripts to read and write and delete data.
  - aexaey 11y ago
    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_destroyer/ http://dangerousprototypes.com/2010/05/25/prototype-flash_de... [2] https://en.wikipedia.org/wiki/Wear_leveling https://en.wikipedia.org/wiki/Wear_leveling
- geerlingguy 11y ago
  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 11y ago
    Thanks for the info :).
guylepage3 11y ago
Thank you for putting this together. Great work
- electricblue 11y ago
  Yeah I was just looking for something like this for my Pi 2 so thanks!
post_break 11y ago
Needs the Lexar 633x and 1000x on there for testing.
deleted 11y ago
[deleted]
thearn4 11y ago
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 11y ago
  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.

180 points by geerlingguy 11y ago

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 11y ago
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 11y ago
  Sorry about that; all are 16GB except the 32GB Evo+, and 8GB Kingston and SanDisk Extreme Pro.
  - Nursie 11y ago
    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 11y ago
      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 11y ago
        Thanks for the info :)
mortenlarsen 11y ago
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.
- ploxiln 11y ago
  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.
  - mortenlarsen 11y ago
    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.
    - reitzensteinm 11y ago
      But apt-get is exactly where you'd expect a ton of random rights.
      - mortenlarsen 11y ago
        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.
    - joosters 11y ago
      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.

geerlingguy 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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.

bcrack 11y ago

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 11y ago
Sometimes sustained reads/writes are a little slower due to RAM size and/or processor speed, but the variations are minor.

odabaxok 11y ago

Here is another list: http://elinux.org/RPi_SD_cards#SD_card_performance http://elinux.org/RPi_SD_cards#SD_card_performance

geerlingguy 11y ago
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.

logicallee 11y ago

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 11y ago
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 11y ago
  write that! :) ( "< 0.1 MB/sec"). Though I wonder if that isn't some faulty issue.
  - geerlingguy 11y ago
    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 11y ago
      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.

rasz_pl 11y ago

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 11y ago
> 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 11y ago
  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 11y ago
    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

mschuster91 11y ago

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 11y ago
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 11y ago
  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.

fulafel 11y ago

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 11y ago
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 11y ago
  If your PG setup leaves writes sitting in the buffer cache after transaction commits, it's not working right.
  - pmontra 11y ago
    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-postgresql-for-large-amounts-of-ram http://dba.stackexchange.com/questions/18484/tuning-postgres...
    - fulafel 11y ago
      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)

johnchristopher 11y ago

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

DanBC 11y ago
A good project for a student group though. Ten RPis, ten cards, some scripts to read and write and delete data.
- aexaey 11y ago
  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_destroyer/ http://dangerousprototypes.com/2010/05/25/prototype-flash_de... [2] https://en.wikipedia.org/wiki/Wear_leveling https://en.wikipedia.org/wiki/Wear_leveling
geerlingguy 11y ago
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 11y ago
  Thanks for the info :).

guylepage3 11y ago

Thank you for putting this together. Great work

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

post_break 11y ago

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

deleted 11y ago

[deleted]

thearn4 11y ago

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 11y ago
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.