Lower Endurance: A Non-Issue

We've mentioned time and time again that NAND endurance is a non-issue for desktop (and even some enterprise) workloads.

Intel doesn't quantify the difference in endurance between the NAND used on the SSD 330 and the 520, it simply states that the 330's NAND will deliver a useful lifespan of 3 years and thus carries a 3 year warranty. Unfortunately, without access to the E2/E3/E4 counters we can't quickly figure out how long the 330 would last given a typical client workload. Thankfully Intel left one SMART wear indicator intact: the E9 attribute, otherwise known as the Media Wearout Indicator.

The normalized value of the E9 attribute (accessible via any SMART monitoring software, or Intel's SSD Toolbox) starts at 100 and decreases, linearly by integer increments, down to 0. Its meaning? The number of cycles the NAND media has undergone. At 100, your NAND is running at roughly full health. At 90, you've exhausted 10% of your NAND's lifespan. By the time the E9/MWI attribute gets down to 1 (99% of NAND p/e cycles have been used up) the counter stops decrementing and you're recommended to replace the drive. Even Intel admits however it's quite likely that at a value of 1 your drive will last for a considerable amount of time.

These are SandForce drives that implement real time data deduplication/compression so I wanted to create the worst case scenario to see how big of a deal this lower endurance NAND would be. I filled the 60GB Intel SSD 330 with incompressible data, leaving only its spare area untouched. I then ran a 4KB random write test, at a queue depth of 32, using incompressible data in four blocks of 6 hours, stopping only to look at the state of the E9/MWI attribute.

Even after 3959GB written to the 60GB drive, the media wear indicator remained at 100. If we do the math and assume that Intel isn't lying about the attribute decreasing linearly from 100 down to 0, it's possible the NAND on this particular 60GB SSD 330 is good for at least 6000 p/e cycles (3959GB/64GB = ~61 p/e cycles per NAND cell).

Not satisfied with these results I went in for another 24 hour round. By the end of it I had written 7629GB to the 60GB drive, at around 119 p/e cycles per NAND cell (assuming perfect wear leveling). The MWI hadn't budged:

Extrapolating based on this data you'd end up with over 10,000 p/e cycles for this particular drive. Whether or not this is accurate remains to be seen, but endurance is clearly not going to be an issue with Intel's SSD 330.

If you assume a typical client drive sees 10GB of writes per day, within a year you'd write 3650GB to the drive. I wrote that much in 24 hours. In fact, I wrote more than two years worth of data to the 60GB Intel SSD 330 in two days. All the while the Intel SSD 330 didn't even blink.

Note that as with any form of binning, you will see examples of drives that do better or worse than the one I've tested. Unless there's something horribly wrong with Intel's 25nm NAND process however, the difference is unlikely to be large enough where it'd be an issue.

As a side benefit to all of this experimenting with death is we can actually quantify write amplification on a SandForce drive.

Intel's 300i firmware, like all SandForce firmware, keeps track of NAND vs. host writes. Using that data I'm able to quantify write amplification during this fairly worst-case scenario workload:


7629GB of NAND writes vs. 1550GB of host writes = ~4.9x write amplification

SandForce maintains extremely low write amplification, even when faced with a hefty workload. Typical write amplification for client users will likely be far lower.

Internal Architecture & The Bundle Random & Sequential Performance
Comments Locked

64 Comments

View All Comments

  • STL - Wednesday, August 1, 2012 - link

    After sending a link to this article to my friend and quoting a sentence (we both follow Intel SSDs, and I bought a 710 300GB based on AnandTech's excellent review), I noticed that AnandTech has begun using the JavaScript thing that infects copied text with "read more at". (As explained at http://daringfireball.net/2010/05/tynt_copy_paste_... , although the "service" provider may be different here.)

    I am *extremely* disappointed to see AnandTech tarnishing its image with this nonsense.
  • Bull Dog - Wednesday, August 1, 2012 - link

    yea, this is a pretty annoying "feature"
  • Anand Lal Shimpi - Wednesday, August 1, 2012 - link

    Hmm this isn't intentional, let me see what's going on.

    Take care,
    Anand
  • iEagle - Wednesday, August 1, 2012 - link

    Here's the culprit:

    <script src='http://i.po.st/share/script/post-widget.js#publish... type='text/javascript'></script>

    i.po.st just got 127.0.0.1'd
  • Zoomer - Wednesday, August 1, 2012 - link

    Good thing it doesn't work on my browser. :)
  • Flying Goat - Wednesday, August 1, 2012 - link

    While it uses compiled Javascript, and I'm too lazy to reformat it, http://i.po.st/static/script/post-copypaste.js is presumably the issue (And blocking that domain gets rid of the problem).

    This is included directly in the source of the article page ("script src='http://i.po.st/share/script/post-widget.js#publish... type='text/javascript'").
  • Anand Lal Shimpi - Wednesday, August 1, 2012 - link

    Fixed, our content sharing partner (po.st) enabled this by default in their latest update. We've stripped it out.

    Take care,
    Anand
  • Zarf42 - Wednesday, August 1, 2012 - link

    And this is why I continue reading Anandtech. You guys are really in tune with your audience and you don't like to annoy us. Thanks for staying awesome!
  • ImSpartacus - Wednesday, August 1, 2012 - link

    I know. I'm such a fanboy. I don't think I'll ever find a site as awesome as Anandtech.
  • STL - Wednesday, August 1, 2012 - link

    Wow, thanks!

Log in

Don't have an account? Sign up now