Performance Consistency

Performance consistency tells us a lot about the architecture of these SSDs and how they handle internal defragmentation. The reason we do not have consistent IO latency with SSDs is because inevitably all controllers have to do some amount of defragmentation or garbage collection in order to continue operating at high speeds. When and how an SSD decides to run its defrag or cleanup routines directly impacts the user experience as inconsistent performance results in application slowdowns.

To test IO consistency, we fill a secure erased SSD with sequential data to ensure that all user accessible LBAs have data associated with them. Next we kick off a 4KB random write workload across all LBAs at a queue depth of 32 using incompressible data. The test is run for just over half an hour and we record instantaneous IOPS every second.

We are also testing drives with added over-provisioning by limiting the LBA range. This gives us a look into the drive’s behavior with varying levels of empty space, which is frankly a more realistic approach for client workloads.

Each of the three graphs has its own purpose. The first one is of the whole duration of the test in log scale. The second and third one zoom into the beginning of steady-state operation (t=1400s) but on different scales: the second one uses log scale for easy comparison whereas the third one uses linear scale for better visualization of differences between drives. Click the dropdown selections below each graph to switch the source data.

For more detailed description of the test and why performance consistency matters, read our original Intel SSD DC S3700 article.

Micron M600 256GB
Default
25% Over-Provisioning

The 1TB M600 actually performs quite significantly worse than the 256GB model, which is most likely due to the tracking overhead that the increased capacity causes (more pages to track). Overall IO consistency has not really changed from the MX100 as Dynamic Write Acceleration only affects burst performance. I suspect the firmware architectures for sustained performance are similar between the MX100 and M600, although with added over-provisioning the M600 is a bit more consistent.

Micron M600 256GB
Default
25% Over-Provisioning

Micron M600 256GB
Default
25% Over-Provisioning

TRIM Validation

To test TRIM, I filled the 128GB M600 with sequential 128KB data and proceeded with a 30-minute random 4KB write (QD32) workload to put the drive into steady-state. After that I TRIM'ed the drive by issuing a quick format in Windows and ran HD Tach to produce the graph below.

It appears that TRIM does not fully recover the SLC cache as the acceleration capacity seems to be only ~7GB. I suspect that giving the drive some idle time would do the trick because it might take a couple of minutes (or more) for the internal garbage collection to finish after issuing a TRIM command.

Introduction, The Drive & The Test AnandTech Storage Bench 2013
Comments Locked

56 Comments

View All Comments

  • nirwander - Monday, September 29, 2014 - link

    First 840 EVO, then MX100...
  • hbarnwheeler - Monday, September 29, 2014 - link

    What explains the data loss? Are you suggesting that DRAM was not being flushed during system suspension?
  • milli - Monday, September 29, 2014 - link

    Damn, I'm having four systems which are having suspend/resume issues. Especially when the system goes into S5 suspend. All four have MX100 drives. Two identical systems with other brand SSD have not such issues.
    I'm not having corruption but sometimes when the computer is resumed from S5, it can't find the drive.
    Bought those drives based on Anand's recommendation. Thx

    Thank you for the link. It will be helpful. Can you confirm that modifying hipm dipm helps?
  • metayoshi - Monday, September 29, 2014 - link

    I wouldn't be so sure as to blame Micron for losing data or getting errors when it comes to Windows suspend and resume. I have had WD, Seagate, and the acquired Fujitsu, Hitachi, and Maxtor HDDs, and Intel, Crucial, and Corsair SSDs, and all of them have had problems when it came to Windows suspend and resume. I never ever use Windows' own Sleep and Hibernate states anymore because of this problem. These power states from Windows are not even supposed to be considered an unexpected power loss by most of these storage industry manufacturers because it is required by the specs for Windows to gracefully flush any cached data and power down the drive before yanking the power to it. As far as I know, all of these drives can handle a graceful power down just fine.

    Unexpected power loss should happen if and only if the user either physically holds down the power of their PC to forcefully shut down the system, or the power cable is physically disconnected from the drive during operation. If an error is happening during suspend and resume, there's usually something wrong that the OS is doing, or something wrong that the OEM system is doing because if there is no graceful power cycle to the storage during suspend and resume, that's the OS's or the OEM's or the BIOS's fault.
  • BedfordTim - Monday, September 29, 2014 - link

    I always disable sleep for that very reason. With my Thinkpad and Vista it never woke, and while things have got better it still happened with Windows 7 on every machine I have tried it on.
  • Lerianis - Friday, October 3, 2014 - link

    O'really? On every single computer I have had, sleep worked without issues. I've had Gateway's, HP's, Acer's, Toshiba's, etc. None of them had problems with sleeping properly in Windows Vista - 8.1.
    I'm thinking that you are exaggerating or just out and out falsifying what actually was going on.
  • leexgx - Saturday, November 1, 2014 - link

    i agree i always sleep my computer and laptops only OS that had a problem with doing it was Vista with Nvidia + creative card (witch was not comptelay VIsta fault) on windows 7 never had an issue with sleep

    i guessing i not had the issue with the 2 512GB MX100 i have (X58 i7-920 systems) as the motherboard i got due not support any of the adv power management features (well i did have to update the firmware in the other system as it was failing after 5 minutes but that system has always been odd, but the firmware update did seem to resolve it or something els i did)
  • leexgx - Saturday, November 1, 2014 - link

    probably bad luck with Drivers and sleep (Drivers are what norm break the sleep, last time i had BSOD issues was related to Sleep and Creative sound drivers)

    not that i need to sleep this system as it boots up in under 20 seconds (but Chrome is compleatly CPU bound when it reopens 40 tabs)
  • Lerianis - Friday, October 3, 2014 - link

    Is this problem/issue present with Windows 8? Or did they fix this issue?
  • shodanshok - Monday, September 29, 2014 - link

    Hi Kristian,
    it seems that Dynamic Write Acceleration is disabled on 512GB and 1 TB disks. From techreport:
    "Surprisingly, the 1TB and 512GB variants don't have Dynamic Write Acceleration. Those drives are already fast enough for the controller, according to Micron, and the math works out. The Marvell chip can address up to four chips on each of its eight memory channels, making 32-die configurations ideal for peak performance. At 16GB per die, the cut-off point is 512GB."

    This is probably the reason behind the 512 GB units having only 50% more endurance that the 256 GB one: DWA on the smaller one can absorb many writes and flush them in sequential form on the MLC array, saving some flash wear (in average).

    Regards.

Log in

Don't have an account? Sign up now