Micron M600 (128GB, 256GB & 1TB) SSD Review
by Kristian Vättö on September 29, 2014 8:00 AM ESTRandom Read/Write Speed
The four corners of SSD performance are as follows: random read, random write, sequential read and sequential write speed. Random accesses are generally small in size, while sequential accesses tend to be larger and thus we have the four Iometer tests we use in all of our reviews.
Our first test writes 4KB in a completely random pattern over an 8GB space of the drive to simulate the sort of random access that you'd see on an OS drive (even this is more stressful than a normal desktop user would see). We perform three concurrent IOs and run the test for 3 minutes. The results reported are in average MB/s over the entire time.
Random performance remains more or less unchanged from the MX100 and M550. Micron has always done well in random performance as long as the IOs are of bursty nature, but Micron's performance consistency under sustained workloads has never been top notch.
Sequential Read/Write Speed
To measure sequential performance we run a 1 minute long 128KB sequential test over the entire span of the drive at a queue depth of 1. The results reported are in average MB/s over the entire test length.
Sequential write performance sees a minor increase at smaller capacities thanks to Dynamic Write Acceleration, but aside from that there is nothing surprising in sequential performance.
AS-SSD Incompressible Sequential Read/Write Performance
The AS-SSD sequential benchmark uses incompressible data for all of its transfers. The result is a pretty big reduction in sequential write speed on SandForce based controllers, but most other controllers are unaffected.
Facebook
Twitter
RSS
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 sleepi 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.