Samsung SSD 840 EVO Review: 120GB, 250GB, 500GB, 750GB & 1TB Models Tested
by Anand Lal Shimpi on July 25, 2013 1:53 PM EST- Posted in
- Storage
- SSDs
- Samsung
- TLC
- Samsung SSD 840
Endurance
Samsung isn't quoting any specific TB written values for how long it expects the EVO to last, although the drive comes with a 3 year warranty. Samsung doesn't explicitly expose total NAND writes in its SMART details but we do get a wear level indicator (SMART attribute 177). The wear level indicator starts at 100 and decreases linearly down to 1 from what I can tell. At 1 the drive will have exceeded all of its rated p/e cycles, but in reality the drive's total endurance can significantly exceed that value.
Kristian calculated around 1000 p/e cycles using the wear level indicator on his 840 sample last year or roughly 242TB of writes, but we've seen reports of much more than that (e.g. this XtremeSystems user who saw around 432TB of writes to a 120GB SSD 840 before it died). I used Kristian's method of mapping sequential writes to the wear level indicator to determine the rated number of p/e cycles on my 120GB EVO sample:
| Samsung SSD 840 EVO Endurance Estimation | |||||||
| Samsung SSD EVO 120GB | |||||||
| Total Sequential Writes | 4338.98 GiB | ||||||
| Wear Level Counter Decrease | -3 (raw value = 35) | ||||||
| Estimated Total Writes | 144632.81 GiB | ||||||
| Estimated Rated P/E Cycles | 1129 cycles | ||||||
Using the 1129 cycle estimate (which is an improvement compared to last year's 840 sample), I put together the table below to put any fears of endurance to rest. I even upped the total NAND writes per day to 50 GiB just to be a bit more aggressive than the typically quoted 10 - 30 GiB for consumer workloads:
| Samsung SSD 840 EVO TurboWrite Buffer Size vs. Capacity | |||||||
| 120GB | 250GB | 500GB | 750GB | 1TB | |||
| NAND Capacity | 128 GiB | 256 GiB | 512 GiB | 768 GiB | 1024 GiB | ||
| NAND Writes per Day | 50 GiB | 50 GiB | 50 GiB | 50 GiB | 50 GiB | ||
| Days per P/E Cycle | 2.56 | 5.12 | 10.24 | 15.36 | 20.48 | ||
| Estimated P/E Cycles | 1129 | 1129 | 1129 | 1129 | 1129 | ||
| Estimated Lifespan in Days | 2890 | 5780 | 11560 | 17341 | 23121 | ||
| Estimated Lifespan in Years | 7.91 | 15.83 | 31.67 | 47.51 | 63.34 | ||
| Estimated Lifespan @ 100 GiB of Writes per Day | 3.95 | 7.91 | 15.83 | 23.75 | 31.67 | ||
Endurance scales linearly with NAND capacity, and the worst case scenario at 50 GiB of writes per day is just under 8 years of constant write endurance. Keep in mind that this is assuming a write amplification of 1, if you're doing 50 GiB of 4KB random writes you'll blow through this a lot sooner. For a client system however you're probably looking at something much lower than 50 GiB per day of total writes to NAND, random IO included.
I also threw in a line of lifespan estimates at 100 GiB of writes per day. It's only in this configuration that we see the 120GB drive drop below 4 years of endurance, again based on a conservative p/e estimate. Even with 100 GiB of NAND writes per day, once you get beyond the 250GB EVO we're back into absolutely ridiculous endurance estimates.
Keep in mind that all of this is based on 1129 p/e cycles, which is likely less than half of what the practical p/e cycle limit on Samsung's 19nm TLC NAND. To go ahead and double those numbers and then you're probably looking at reality. Endurance isn't a concern for client systems using the 840 EVO.
Facebook
Twitter
RSS
137 Comments
View All Comments
Riven98 - Thursday, July 25, 2013 - link
Anand,Thanks for the great article. I had just been thinking that there had been a downturn in the number of articles like these, which are the main reasons I visit on an almost daily basis.
chrnochime - Friday, July 26, 2013 - link
Still recommending a technology that's known to not last as long as the MLC. Yes the *extropolated* result indicates that its lifetime is far longer than advertised, but really, why when even M500 is not that slow in the first place and cost about the same, why risk going with the TLC? Not to mention Samsung's 830 has its fair share of horror stories as well...watersb - Friday, July 26, 2013 - link
Excellent review.How does write amplification scale as the disk fills up? Wouldn't a full disk fail more rapidly than a half-full one?
BobAjob2000 - Tuesday, January 28, 2014 - link
Hopefully wear leveling and TRIM/garbage collection algorithms should take care of your concerns. They should take existing unchanged 'cold' data and move it around to make way for regularly changed 'hot' data. This should reduce the impact of both data longevity and write amplification as it guides new writes to hit the 'freshest' unused or rarely written blocks on the disk and also helps to ensure that data goes not go 'stale' after being untouched for years. Different vendors use different algorithms that have evolved and improved over time. I think Samsung (being a RAM manufacturer) can possibly provide better RAM caches for their disks that may provide advantages for garbage collection and wear leveling algorithms by improving the available 'thinking space' for the caching and sorting/organizing of 'hot' data.Its all to do with managing the 'temperature' of your data somewhat like a data 'weather forecast' which can be very useful in the short term or for simple predictable/settled patterns but less practical for long term or unseasonal data storms.
Would like to see these things tested by 'what if' scenarios though to demonstrate the differences between different vendors algorithms.
xtreme2k - Friday, July 26, 2013 - link
Can anyone tell me why I am paying 90% of the price for 33% of the endurance of a drive?MrSpadge - Saturday, July 27, 2013 - link
Because endurance doesn't matter (very likely also for you), but price does.log - Friday, July 26, 2013 - link
Can you partition this drive and still take advantage of its features? ThnaksTimur Born - Friday, July 26, 2013 - link
I don't quite understand exactly why the Samsung RAPID software cache brings higher performance in *practice* than Windows' own cache? Using two software caches will lead to the same information being stored in RAM twice or even thrice, which is exactly what the Windows cache tries to avoid since XP days.That the usual benchmark programs get fooled is visible, as they think to be working without a software cache. So the higher values there are not surprising. But I am a bit puzzled why the Anand Storage Bench results increase, too?! Why is RAPID software caching better than Windows' own cache in this scenario? Or does the ASB bypass Windows' cache, too (like most benchmarks)?
By the way: ATTO allows the Windows cache to be turned ON for testing. My "old" Crucial M4 256 gets sees very high read results once ATTO makes use of Windows' cache. Only the write rates remain significantly smaller.
Therefor an ATTO test with combinations of either or both software caches (RAPID and Windows) would be interesting.
MrSpadge - Saturday, July 27, 2013 - link
I think it's because Samsung is being much more agressive with caching than Win dares to be, i.e. it holds files far longer before writing them, so they can be combined more efficiently but are longer at risk of being lost.Timur Born - Sunday, July 28, 2013 - link
I am not convinced about that yet, especially since you can turn off drive cache flushing via Device-Manager and thus should get an even more aggressive Windows cache behavior than what RAPID offers (which is reported to adhere to Windows' flush commands).The Windows cache is designed to keep data in RAM for as long as it's not needed for something else. Even more important, data is *directly* executed from inside the Windows cache instead of being copied back and forth between separate memory regions. This keeps duplication to a minimum (implemented since XP as far as I remember). So at least for reads the Windows cache is very useful, especially in combination with Superfetch, which is *not* disabled for SSDs btw (even Prefetch for the boot phase isn't disabled, but in practice it makes not much of a difference whether you boot with or without Prefetch from an SSD).
There is something funky going on with Windows' cache and the drive's onboard cache of my Crucial M4 in combination with ATTO (Windows cache enabled). Different block sizes get very different results, with some *larger* block sizes not benefiting from Windows' cache either at read or write, the latter depending on the block size chosen. Turning the drive's own cache flushing on/off via Device-Manager can have an impact on that, too.
In some cases I get less throughput with Windows cache than without (i.e. 512 kb block size with drive flushing on). This may be an issue of ATTO, though, because I also got some measurements where ATTO claimed a write speed of zero (0)! Turning off either drive cache flushing or the Windows cache or both helps ATTO to get meaningful measurements again.
So the main question remains: How and why would RAPID affect "real-world" performance on top of the Windows cache and does the Anand Storage Bench deliberately circumvent the Windows cache?
The reason I was looking at this review was that I am currently looking for a new SSD to build a desktop PC and the 840 EVO looks like the thing to buy. So once I get my hands on one myself I will just try RAPID myself. ;)