The 2TB Samsung 850 Pro & EVO SSD Reviewby Kristian Vättö on July 23, 2015 10:00 AM EST
AnandTech Storage Bench - The Destroyer
The Destroyer has been an essential part of our SSD test suite for nearly two years now. It was crafted to provide a benchmark for very IO intensive workloads, which is where you most often notice the difference between drives. It's not necessarily the most relevant test to an average user, but for anyone with a heavier IO workload The Destroyer should do a good job at characterizing performance. For full details of this test, please refer to this article.
The 2TB Pro appears to be marginally slower than the 1TB model, but honestly we are talking about a ~5% difference. As I mentioned on the previous page, managing more NAND requires more controller resources and since the MHX is fundamentally an MEX with a beefier DRAM controller, a tiny performance hit is normal and despite that the 2TB Pro and EVO are still the fastest SATA drives on the market.
There's an increase in >10ms IOs, which I suspect is again due to the higher performance variation caused by the additional management resources required by the extra NAND.
The 2TB Pro turns out to have better power efficiency than its 512GB sibling. Normally smaller drives are more efficient due to having less NAND drawing power, but it may very well be that Samsung has moved to a more power efficient process node for the MHX controller, which would explain the lower power consumption.
Post Your CommentPlease log in or sign up to comment.
View All Comments
vFunct - Thursday, July 23, 2015 - linkAny info about the well known TRIM bug in these drives?
vFunct - Thursday, July 23, 2015 - linkTRIM bug reported here: https://blog.algolia.com/when-solid-state-drives-a...
Kristian Vättö - Thursday, July 23, 2015 - linkThe bug turned out to be in the Linux kernel, not in Samsung SSDs, as you can see in the first link once you scroll down the updates. Samsung has developed a kernel patch to fix the issue too.
BillyONeal - Thursday, July 23, 2015 - linkWell they patched the kernel to work around the firmware bug; but that doesn't mean it was a kernel bug.
Kristian Vättö - Thursday, July 23, 2015 - linkThere was never a problem with TRIM under Windows or OS X.
DanNeely - Thursday, July 23, 2015 - linkIF you follow through to the mailing list discussion for the bug fix, the problem is with the kernel overwriting a pointer when it shouldn't be. If I'm following it correctly, it impacts any SSD brand in RAID0 with trim enabled.
leexgx - Thursday, July 23, 2015 - linkdid not affect the Intel SSDs
mooninite - Thursday, July 23, 2015 - linkKristian,
There are two forms of TRIM these days. The original, Windows-supported, inline TRIM and the latest, queued TRIM. The latter is what is the problem on Samsung drives. I encourage you to fully investigate the issue.
Inline TRIM is known to cause delays with certain drives and certain host systems because it can take over IO on a drive and freeze other commands until TRIM is complete. The number of drives and systems effected is quite low, but it is enough for some people to disable TRIM or use a nightly TRIM script (fstrim).
sustainednotburst - Friday, July 24, 2015 - linkAlgolia stated Queued Trim is disabled on their systems, so its not related to Queued Trim.
editorsorgtfo - Thursday, July 23, 2015 - linkThat was my first reaction, too. But judging from the message on the mailing list and the patch, it is indeed a kernel issue and not specific to Samsung drives. It seems so stem from using queued TRIM on software RAID0, which is a moderately questionable configuration anyway. I guess Algolia did not tell the whole (probably embarrassing) story since there is only one mention of Linux software RAID in the entire article. Maybe they didn't configure their Intel drives the same way?
I was set on an Intel 730 for a 7mm SATA role up until a few minutes ago because I had read about this, too. But in light of this, one can probably use Kristian's "best 6Gbps SATA SSD" without excessive worry.