SSD Deathmatch: Crucial's M500 Vs. Samsung's 840 EVO

Head To Head: Crucial's M500s Vs. Samsung's 840 EVOs

The M500s And 840 EVOs Mix It Up

Samsung recently sent us four different capacities of its 840 EVO. As it turns out, we also have four Crucial M500s, one of which came to us from our German team, one that was sampled by Crucial, and two we bought online. Naturally, we wanted to know how they match up against each other.

These drives aren't always going to fit the same applications, but they clearly have more than a few attributes in common, despite their dissimilarities. The M500s are built using 128 Gb, two-bit-per-cell MLC, feature RAIN redundancy, and power loss protection. The 840 EVO does its work with three-bit-per-cell flash, emulated SLC caching, and, well, that's it, mostly.

Samsung's new offerings don't offer the same TCG Opal 2.0 and eDrive security...at least not yet. With eDrive, cryptographic functions are hardware-accelerated, and Microsoft's built-into-Windows BitLocker can exploit it in Windows 8. That's going to get added to the 840 EVO in an upcoming firmware release. In contrast, the M500 is loaded with security features. I made the mistake of referring to the M500's security and encryption as just "fairly high-end," and was quickly interrupted by Micron representatives, who pointed out that, at the time, it had the highest-end suite of security features available. That's a fair point, and true as of this moment, though probably not for long.

So how about a few direct performance comparisons? 

M500 Vs. 840 EVO : Sequential Read And Write

This is a chart housing four other charts, showing sequential read scaling versus sequential write scaling. The first graph pits the 120 GB M500 against Samsung's 120 GB 840 EVO, and so on. The M500s are shown in blue, and the 840 EVOs are purple.

Samsung enjoys an advantage over the M500s. At every capacity, read and write performance belongs to the 840 EVO. As far as reads go, specifically, the M500s start off a bit slower and don't ramp up to the 840's speed until we use a queue depth of four. This could be an artifact of the way Iometer's tests are performed, but there's a 200 MB/s gap between the drives at a queue depth of one.

The writes are more complicated. Samsung employs its Turbo Write emulated SLC caching scheme to improve performance. At first, we push too much data into the buffer to achieve optimal performance on the 840 EVOs, so the write numbers aren't what they should be. Without that cache, the EVOs are no faster than Samsung's original 840 (in other words, equal to or slower than the M500). But you won't see that here.

The situation gets even stickier when we test with random 4 KB blocks.

M500 Vs. 840 EVO : Random Read And Write

At a queue depth of one, both vendors nail high 4 KB results. The 840 EVO enjoys an edge as the three larger capacities break 10,000 IOPS. The M500s hold their own, though they lose out to the current random read champion at a queue depth of one. From there, though the gap narrows, the 840 EVOs maintain their lead, even at higher queue depths.

Random writes play out a bit differently. The 120 GB 840 EVO chokes early, dropping down into scandalously-low numbers at a queue depth of one. Otherwise, we essentially get a wash from the three larger-capacity SSDs in each family. 

  • Someone Somewhere
    I think you mixed up the axis on the read vs write delay graph. It doesn't agree with the individual ones after, or the writeup.
    Reply
  • Someone Somewhere
    Even 3bpc SSDs should last you a good ten years...

    The SSD 840 is rated for 1000 P/E cycles, though it's been seen doing more like ~3000. At 10GB/day, a 240GB would last for 24,000 days, or about 766 years, and that's using the 1K figure.

    You're free to waste money if you want, but SLC now has little place outside write-heavy DB storage.

    EDIT: Screwed up by an order of magnitude.
    Reply
  • cryan
    11306005 said:
    I think you mixed up the axis on the read vs write delay graph. It doesn't agree with the individual ones after, or the writeup.

    You are totally correct! You win a gold star, because I didn't even notice. Thanks for catching it, and it should be fixed now.

    Regards,
    Christopher Ryan

    Reply
  • cryan
    11306034 said:
    I would only buy SSD that uses SLC memory. I dont wan't to buy new drive every year or so.

    Not only are consumer workloads completely gentle on SSDs, but modern controllers are super awesome at expanding NAND longevity. I was able to burn through 3000+ PE cycles on the Samsung 840 last year, and it only is rated at 1,000 PE cycles or so. You'd have to put almost 1 TB a day on a 120 GB Samsung 840 TLC to kill it in a year, assuming it didn't die from something else first.

    Regards,
    Christopher Ryan

    Reply
  • Someone Somewhere
    I'd like to see some sources on that - for starters, I don't think the 840 has been out for a year, and it was the first to commercialize 3bpc NAND.

    You may be thinking of the controller failures some of the Sandforce drives had, which are completely unrelated to the type of NAND used.
    Reply
  • mironso
    Well, I must agree with Someone Somewhere. I would also like to see sources for this statement: "Yes, in theory they last 10 years, in practise they last a year or so.".
    I would like to see, can TH use SSD put this 10GB/day and see for how long it will work.
    After this I read this article, I think that Crucial's M500 hit the jackpot. Will see Samsung's response. And that's very good for end consumer.
    Reply
  • edlivian
    It was sad that they did not include the samsung 830 128gb and crucial m4 128gb in the results, those were the most popular ssd last year.
    Reply
  • Someone Somewhere
    You can also find tens of thousands of people not complaining about their SSD failing. It's called selection bias.

    Show me a report with a reasonable sample size (more than a couple of dozen drives) that says they have >50% annual failures.

    A couple of years ago Tom's posted this: http://www.tomshardware.com/reviews/ssd-reliability-failure-rate,2923.html

    The majority of failures were firmware-caused by early Sandforce drives. That's gone now.

    EDIT: Missed your post. First off, that's a perfect example of self-selection. Secondly, those who buy multiple SSDs will appear to have n times the actual failure rate, because if any fail they all appear to fail. Thirdly, that has nothing to do with whether or not it is a 1bpc or 3 bpc SSD - that's what you started off with.

    This doesn't fix the problem of audience self-selection
    Reply
  • Someone Somewhere
    You were however trying to stop other people buying them...

    Sounds a bit like a sore loser argument, unfortunately.

    SSDs aren't perfect, but they generally do live long enough to not be a problem. Most of the failures have been overcome by now too.

    Just realised there's an error in my original post - off by a factor of ten. Should have been 66 years.
    Reply
  • warmon6
    11306841 said:
    I am not talking about Samsung SSD-s, I am talking about SSDs in general. And I am not going to provide any sources because SSD fail all the time after a year or so. That is the raility. You can find, on the internet, people complaining abouth their SSD failing. There are a lot of them...
    Also, SLC based SSD-s are usually "enterprise", so they are designed for reliability and not performance, and they don't use some bollocks, overclocked to the point of failure, controllers. And have better optimised firmware...

    Tell that to all the people on this forum still running intel X-25M that launched all the way back in 2008 and my Samsung 830 that's been working just fine for over a year.......

    See what you're paying attention too is the loudest group of ssd owners. The owners that have failed ssd's.

    See it's the classic "if someone has a problem, there going to be the one that you hear and the quiet group, isn't having the problem" issue.

    Those that dont have issues (such as myself) dont mention about our ssds and is probably complaining about something else that has failed.


    Reply