Performance Consistency

We've been looking at performance consistency since the Intel SSD DC S3700 review in late 2012 and it has become one of the cornerstones of our SSD reviews. Back in the days many SSD vendors were only focusing on high peak performance, which unfortunately came at the cost of sustained performance. In other words, the drives would push high IOPS in certain synthetic scenarios to provide nice marketing numbers, but as soon as you pushed the drive for more than a few minutes you could easily run into hiccups caused by poor performance consistency. 

Once we started exploring IO consistency, nearly all SSD manufacturers made a move to improve consistency and for the 2015 suite, I haven't made any significant changes to the methodology we use to test IO consistency. The biggest change is the move from VDBench to Iometer 1.1.0 as the benchmarking software and I've also extended the test from 2000 seconds to a full hour to ensure that all drives hit steady-state during the test.

For better readability, I now provide bar graphs with the first one being an average IOPS of the last 400 seconds and the second graph displaying the IOPS divided by standard deviation during the same period. Average IOPS provides a quick look into overall performance, but it can easily hide bad consistency, so looking at standard deviation is necessary for a complete look into consistency.

I'm still providing the same scatter graphs too, of course. However, I decided to dump the logarithmic graphs and go linear-only since logarithmic graphs aren't as accurate and can be hard to interpret for those who aren't familiar with them. I provide two graphs: one that includes the whole duration of the test and another that focuses on the last 400 seconds of the test to get a better scope into steady-state performance. These results are for all drives 240GB and up.

Steady-State 4KB Random Write Performance

In steady-state 4KB random write performance the EVO is actually slightly faster than the Pro, but given that the EVO employs more over-provisioning (12% vs 7%), it's not out of the ordinary. The 2TB EVO performs slightly lower than the 1TB model, so it seems that despite the upgraded DRAM controller the controller may not be ideal for more than 1TB of NAND (internal SRAM caches and the like are the same as in the MEX controller). Nevertheless, the difference isn't substantial and in any case the Pro and EVO both boast excellent steady-state performance.

Steady-State 4KB Random Write Consistency

Both 2TB drives also have great consistency, although the 2TB Pro can't challenge the 512GB Pro that clearly leads the consistency graph. Given the same amount of raw processing power, managing less NAND is obviously easier because the more NAND there is, the more garbage collection calculations the controller has to process, which results in increased variation in performance.

Samsung 850 Pro 2TB
25% Over-Provisioning

The behavior in steady-state is similar to other 850 Pro and EVO drives, which is hardly surprising given the underlying firmware similarities. One area to note, though, is the increased performance variation with additional over-provisioning (OP), whereas especially the 512GB Pro presents very consistent performance with 25% OP. In any case, performance with additional OP is class-leading in both Pro and EVO.

Samsung 850 Pro 2TB
25% Over-Provisioning
Introduction, The Drives & The Test AnandTech Storage Bench - The Destroyer
Comments Locked


View All Comments

  • vFunct - Thursday, July 23, 2015 - link

    Any info about the well known TRIM bug in these drives?
  • vFunct - Thursday, July 23, 2015 - link

    TRIM bug reported here:

    and here:
  • Kristian Vättö - Thursday, July 23, 2015 - link

    The 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 - link

    Well 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 - link

    There was never a problem with TRIM under Windows or OS X.
  • DanNeely - Thursday, July 23, 2015 - link

    IF 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 - link

    did not affect the Intel SSDs
  • mooninite - Thursday, July 23, 2015 - link


    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 - link

    Algolia stated Queued Trim is disabled on their systems, so its not related to Queued Trim.
  • editorsorgtfo - Thursday, July 23, 2015 - link

    That 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.

Log in

Don't have an account? Sign up now