Micron M600 SSD Review - Digging into Dynamic Write Acceleration
Dynamic Write Acceleration
One of the main things Micron has struggled with over the past few generations of SSDs has been write speeds. Take a look at this older spec sheet:
Note the sequential write speeds of the MX100 and M550. Giving clearer detail on these specs, the MX100 write specs are 150, 300, and 500 MB/sec. The primary reason for this is simply the Marvell controller combined with IMFT flash can only yield this maximum speed when that write data must be spread across 128Gbit (16GB) flash memory dies. The 128GB models have only 8 of those dies, so it's easy to see how all dies can be busily writing and the controller left waiting for those writes to complete.
Micron improved on this with the M550. While the above specs list 190MB/sec, that minimum rating is for the 64GB model. The 128GB model gets 350MB/sec (up from 150MB/sec of the MX100 at that same capacity). The cause for this improvement was the use of 64Gbit dies. These smaller (8GB) capacity dies mean a given capacity SSD can have 2x the die count, and that increased parallelism means more dies busy writing, and therefore greater overall write speeds.
Fast forward to the M600. Micron wanted to use their new 16nm flash memory in this product, but there was a catch - that flash is only available in 128GBit dies. This could potentially throw the new product into MX100 performance territory, but Micron had a solution - Dynamic Write Acceleration.
What is it?
Dynamic Write Accleration is realized by the ability of Micron's 16nm NAND to be switched between SLC and MLC modes 'on the fly'. In short, a new and empty M600 SSD will have its dies in SLC mode. While the SSD will appear to the user at its rated capacity, the actual flash capacity in SLC mode is half of what it would be if all dies were in MLC mode. As the SSD is filled past 50% capacity, the controller intelligently switches dies from SLC to MLC, shuffling data around as necessary in the background to briefly empty a given die before switching its mode.
The end result, as explained by Micron, is seen above. Since SLC mode flash writes faster than MLC, writes to the new M600's should be very fast. A note of distinction is that Dynamoc Write Acceleration is *not* a cache. Data written to SLC mode flash dies is left there until the SSD has been filled enough to warrant that data being shifted to MLC mode flash dies. If an M600 was never filled >50%, it would in theory remain in SLC mode indefinitely.
As you may imagine, this does add a level of complexity, as well as some complications for situations where continuous writes force the M600 to do its 'die flipping', normally a background operation, in the foreground:
Pictured above is what an M600 would do if you filled it to capacity in one sitting. Once SLC dies are exhausted, accelerated (SLC) speeds drop to standard (MLC) speeds. Without idle time for the M600 to shuffle data and flip additional dies over to MLC mode, it is forced to begin that process *while* the user data is being written from the host, which results in an even slower speed. In normal usage scenarios, the M600 should not be completely caught off guard and reach this slowest speed, as most users don't fill their entire SSD in one sitting, and with no idle time. Micron assures us that even at 95% capacity, the M600 will have more SLC mode flash available for writing than an equivalent 'competing SSD' (the 840 EVO).
As indicated above, the 840 EVO's SLC area is most definitely static, and unlike the M600, is treated as a pure cache. Data written to an EVO goes straight to SLC, and is immediately unloaded to TLC flash as soon as the drive sees idle time. We have tested this, and it does function as advertiesd. If the cache is filled by a large continuous write, the EVO will continue writing directly to TLC, and at TLC write speed (slightly slower than an equivalent M600 in MLC mode).
The 840 EVO issue:
There is a current issue with 840 EVO TLC flash reads, where read speed slows as weeks pass. Samsung is currently working on this and is expected to release a firmware in the next two weeks. I'm going to give them the benefit of the doubt that the issue will be resolved, so for the purposes of this review, I will include comparison data from 840 EVO's. After all, the speeds are fine so long as we don't leave stale data on them for a few months.