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.

AnandTech Storage Bench - The Destroyer (Data Rate)

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.

AnandTech Storage Bench - The Destroyer (Latency)

AnandTech Storage Bench - The Destroyer (Latency)

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.

AnandTech Storage Bench - The Destroyer (Latency)

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.

AnandTech Storage Bench - The Destroyer (Power)

Performance Consistency AnandTech Storage Bench - Heavy
POST A COMMENT

66 Comments

View All Comments

  • leexgx - Thursday, July 23, 2015 - link

    the bug is related to the incorrect Qued trim support on the Samsung drives

    the samsung drives says they support Qued Trim support but they failed to implement it correctly when they added SATA 3.2 in the latest firmware updates, the Old firmware did not have Qued trim bug because the SSD did not advertise support for it, other SSDs that advertise Qued support it have been patched or don't have the buggy support to start off with (accept the m500)
    Reply
  • editorsorgtfo - Thursday, July 23, 2015 - link

    Can you corroborate this? Nothing in the patch hints at a vendor issue. Reply
  • leexgx - Thursday, July 23, 2015 - link

    i guess this is relating to RAID , there is a failed implementation of advertised Queued Trim support in the samsung 840 and 850 evo/pro drives (the drive says it supports it but it does not support it correctly so TRIM commands are issued incorrectly as to why there is a black list for all 840* and 850* drives)

    your post seems to be related to RAID and kernel issue (but the issue did not happen on Intel drives that they changed to) they rebuilt there intel SSD setups the same as the samsung ones

    they did the same auto restore only the drives changed they had 0 problems once they changed to intel/"other whatever it was" SSDs that also supported Qued TRIM even thought they was not using it the RAID bit probably was (was a bit ago when i looked at it)
    Reply
  • sustainednotburst - Friday, July 24, 2015 - link

    Algolia stated Queued Trim is disabled on their systems, so its not related to Queued Trim. Reply
  • leexgx - Saturday, July 25, 2015 - link

    the problem with samsung drives and Qued trim is till there (not just fake qued trim they failed to implement they also failed to implement the 3.2 spec and the advertised features that samsung is exposing) Reply
  • Gigaplex - Thursday, July 23, 2015 - link

    Those two links show separate bugs. The algolia reported bug was a kernel issue. The second bug which vFunct was probably referring to is a firmware bug where the SSD advertises queued TRIM support but does not handle it correctly. The kernel works around this by blacklisting queued TRIM from known-bad drives. Windows doesn't support queued TRIM at all which is why you don't see the issue there yet. Reply
  • jann5s - Thursday, July 23, 2015 - link

    @AT: please do some data retention measurements with SSD drives! I'm so curious to see if the myth is true and to what extent! Reply
  • Shadowmaster625 - Thursday, July 23, 2015 - link

    With 2 whole gigabytes of DRAM, why are random writes not saturating the SATA bus? Reply
  • Kristian Vättö - Thursday, July 23, 2015 - link

    The extra DRAM is needed for the NAND mapping table, it's not used to cache any more host IOs. Reply
  • KaarlisK - Thursday, July 23, 2015 - link

    Where did TRIM validation go? (The initial approach, which checked whether TRIM restored performance on a filled drive).
    Considering that controllers have had problems with TRIM not restoring performance, even if this is a minor revision, it still seems an important aspect to test.
    Reply

Log in

Don't have an account? Sign up now