Micron M500DC (480GB & 800GB) Review
by Kristian Vättö on April 22, 2014 2:35 PM ESTPerformance Consistency
Performance consistency tells us a lot about the architecture of these SSDs and how they handle internal defragmentation. The reason we don’t 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 buttons 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 M500DC | Crucial M500 | Micron P400e | Micron P400m | Intel SSD DC S3500 | |||||
| Default |
|
||||||||
As you would expect with such hefty over-provisioning, the IO consistency is excellent. The 480GB model manages around 40K IOPS at steady-state, which is certainly one of the highest we have tested. (For the record, the Intel DC S3700 does about 33K but unfortunately there wasn't room in the table to include it.) The 800GB version doesn't do as well given its smaller over-provisioning percentage but it's relatively competitive with the 200GB P400m, which has 336GiB of NAND onboard (that's 44.6% total over-provisioning versus 27.2% in the 800GB M500DC). Compared with the P400m, the M500DC is, after all, a nice upgrade because it's able to improve IO consistency without using more over-provisioning to do that.
 |
|||||||||
| Micron M500DC | Crucial M500 | Micron P400e | Micron P400m | Intel SSD DC S3500 | |||||
| Default |
|
||||||||
 |
|||||||||
| Micron M500DC | Crucial M500 | Micron P400e | Micron P400m | Intel SSD DC S3500 | |||||
|
Default |
|
||||||||
In addition to our regular performance consistency graphs, I decided to include two additional graphs that test the IO consistency over a longer period of time. For client drives, 2000 seconds is generally enough to show steady-state behavior but enterprise SSDs tend to have more over-provisioning and hence require a longer time to reach steady-state. Instead of running the test for 2000 seconds, I extended the run to 7200 seconds (i.e. two hours) while keeping everything else the same. I only have results for the M500DC drives right now, but let's see if anything changes with a longer test cycle:
As you can see, neither of the drives show steady behavior right after 2000 seconds. In fact, it looks as though the initial trigger of data reordering drops performance and then the M500DC drives recover somewhat around the 3000 second mark, though the different amount of overprovisioning means they don't look all that similar. Unfortunately I don't have any results for other drives at this point but I'll be sure to test more drives before the next review to give you a better picture ot the M500DC's position in the market.
Facebook
Twitter
RSS
37 Comments
View All Comments
abufrejoval - Monday, April 28, 2014 - link
I'm seen an opportunity here to clarify something that I've always wondered about:How exactly does this long time retention work for FLASH?
In the old days, when you had an SSD, you weren't very likely having it lie around, after you paid an arm and a leg for it.
These days, however, storing your most valuable data on an SSD almost seems logical, because one of my nightmares is dropping that very last backup magnetic drive, just when I'm trying to insert it after a complete loss of my primary active copy: SSD just seems so much more reliable!
And then there comes this retention figure...
So what happens when I re-insert an SSD, that has been lying around say for 9 months with those most valuable baby pics of your grown up children?
Does just powering it up mean all those flash cells with logical 1's in them will magically draw in charge like some sort of electron sponge?
Or will the drive have to go through a complete read-check/overwrite cycle depending on how near blocks have come to the electron depletion limit?
How would it know the time delta? How would I know it's finished the refresh and it's safe to put it away for another 9 months?
I have some older FusionIO 320GB MLC drives in the cupboard, that haven't been powered up for more than a year: Can I expect them to look blank?
P.S. Yes, you need an edit button and a resizable box for text entry!
Kristian Vättö - Tuesday, April 29, 2014 - link
The way NAND flash works is that electrons are injected to what is called a floating gate, which is insulated from the other parts of the transistor. As it is insulated, the electrons can't escape the floating gate and thus SSDs are able to hold the data. However, as the SSD is written to, the insulating layer will wear out, which decreases its ability to insulate the floating gate (i.e. make sure the electrons don't escape). That causes the decrease in data retention time.Figuring out the exact data retention time isn't really possible. At the maximum endurance, it should be 1 year for client drives and 3 months for enterprise drives but anything before and after is subject to several variables that the end-user don't have access to.
Solid State Brain - Tuesday, April 29, 2014 - link
Data retention depends mainly on NAND wear. It's the highest (several years - I've read 10+ years even for TLC memory though) at 0 P/E cycles and decreases with usage. By JEDEC specifications, consumer SSDs are to be considered at "end life" when the minimum retention time drops below 1 year, and that's what you should expect when reaching the P/E "limit" (which is not actually a hard limit, just a threshold based on those JEDEC-spec requirements). For enterprise drives it's 3 months. Storage temperature will also affect retention. If you store your drives in a cool place when unpowered, their retention time will be longer. By JEDEC specifications the 1 year time for consumer drives is at 30C, while the 3 months time for enterprise one is at 40C. Tidbit: manufacturers use to bake NAND memory in low temperature ovens to simulate high wear usage scenarios during tests.To be refreshed, data has to be reprogrammed again. Just powering up an SSD is not going to reset the retention time for the existing data, it's only going to make it temporarily slow down.
When powered, the SSD's internal controller keeps track of when writes occurred and reprograms old blocks as needed to make sure that data retention is maintained and consistent across all data. This is part of the wear leveling process, which usually is pretty efficient in keeping block usage consistent. However, I speculate this can happen only to a certain extent/rate. A worn drive left unpowered for a long time should preferably have its data dumped somewhere and then cloned back, to be sure that all NAND blocks have been refreshed and that their retention time has been reset to what their wear status allow.
hojnikb - Wednesday, April 23, 2014 - link
TLC is far from crap (well quality one that is). And no, TLC does not have issues holding a "charge". Jedec states a minimum of 1 year of data retention, so your statement is complete bullshit.apudapus - Wednesday, April 23, 2014 - link
TLC does have issues but the issues can be mitigated. A drive made up of TLC NAND requires much stronger ECC compared to MLC and SLC.Notmyusualid - Tuesday, April 22, 2014 - link
My SLC X25-E 64GB is still chugging along, with not so much as a hiccup.It n e v e r slows down, it 'felt' fast constantly, not matter what is going on.
In about that time I've had one failed OCZ 128GB disk (early Indullix I think), one failed Kingston V100, one failed Corsair 100GB too (model forgotten), a 160GB X25-M arrived DOA (but it's replacement is still going strong in a workstation), and late last year a failed Patriot Wildfire 240GB.
The two 840 Evo 250GB disks I have (TLC) are absolute garbage. So bad I had to remove them from the RAID0, and run them individually. When you want to over-write all the free space - you'd better have some time on your hands.
SLC for the win.
Solid State Brain - Wednesday, April 23, 2014 - link
The X25-E 64 GB actually has 80 GiB of NAND memory on its PCB. Since of these only 64 GB (-> 59.6 GiB) are available to the user, it means that about 25% of it is overprovisining area. The drive is obviously going to excel in performance consistency (at least for its time).On the other hand, the 840 250 GB EVO has less OP than the previous 840 models with TLC memory, as you have to subtract 9 GiB from the 23.17 GiB amount of unavailable space (256 GiB of physically installed NAND - 250 GB->232.83 GiB of user space) previously fully used as overprovisioning area, for the Turbowrite feature. This means that in trim-less or intensive write environments with little or no free space they're not going to be that great in performance consistency.
If you were going to use The Samsung 840 EVOs in a RAID-0 configuration you should really had at the very least to increase the OP area by setting up trimmed, unallocated space. So, it's not really that they are "absolute garbage" (as they obviously they aren't) and it's really inherently due to the TLC memory. It's your fault in that you most likely didn't take the necessary steps to use them properly with your RAID configuration.
Solid State Brain - Wednesday, April 23, 2014 - link
I meant:*...and it's NOT really inherently due to the...
TheWrongChristian - Friday, April 25, 2014 - link
> When you want to over-write all the free space - you'd better have some time on your hands.Why would you overwrite all the free space? Can't you TRIM the drives?
Any why run them in RAID0? Can't you use them as JBOD, and combine volumes?
SLC versus TLC results in a about a factor of 4 cheaper just based on a die area basis. That's why drives are MLC and TLC based, the extra storage being used to add extra spare area to make the drive more economical over the drives useful life. Your SLC x25-e, on the other hand, will probably never ever reach it's P/E limit before you discard it for a more useful, faster, bigger replacement drive. We'll probably have practical memrister based drives before the x25-e uses all it's P/E cycles.
zodiacsoulmate - Tuesday, April 22, 2014 - link
It make me think about my OCZ vector 256GB, it breaks everytime there is power lose, even hard reset...There are quite a lot people claim this problem online, and Vector 256GB became only sale refurbised before any other vector drive....
I RMAed two of them, and OCZ replaced mine with Vector 150, which seems fine now.. maybe we should add power lost test to SSDs...