Mixed Random Read/Write Performance

For full details of how we conduct our Iometer tests, please refer to this article.

Iometer - Mixed 4KB Random Read/Write

In mixed 4KB random performance the 2TB Pro shows rather significant gains over the 512GB model. I was always surprised how poorly the 850 Pro performed in this test, so it's good to see Samsung paying attention to this, especially since the performance increase comes with dramatically improved power efficiency.

Iometer - Mixed 4KB Random Read/Write (Power)

Samsung 850 Pro 2TB

The 512GB Pro had performance and power issues once over half of the IOs were writes, but the 2TB model shows quite optimal performance scaling.

Mixed Sequential Read/Write Performance

Iometer - Mixed 128KB Sequential Read/Write

In mixed sequential workload performance of both the 2TB Pro and EVO is further improved with the Pro topping the chart. The 2TB EVO is again more power efficient than the 1TB model, whereas the 2TB Pro consumes only a little more power than the 512GB model (this was expected because large sequential IOs utilize multiple dies and with 2TB having more NAND there are more dies drawing power).

Iometer - Mixed 128KB Sequential Read/Write (Power)

The improvement has been in the critical 60/40 and 40/60 distributions. Quite a few drives have an infamous "bathtub" curve where performance severely degrades, but the 2TB Pro and EVO are fairly consistent though all distributions. It's great to see Samsung improving mixed performance because typically it has been an area that has been forgotten in client SSDs, but under real world workloads IOs tend consist of both reads and writes.

Samsung 850 Pro 2TB
Sequential Performance Idle Power Consumption, ATTO & AS-SSD
Comments Locked

66 Comments

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: https://blog.algolia.com/when-solid-state-drives-a...

    and here:

    https://bugs.launchpad.net/ubuntu/+source/fstrim/+...
  • 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

    Kristian,

    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