The Crucial m4 (Micron C400) SSD Review
by Anand Lal Shimpi on March 31, 2011 3:16 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.
Note that we've updated our C300 results on our new Sandy Bridge platform for these Iometer tests. As a result you'll see some higher scores for this drive (mostly with our 6Gbps numbers) for direct comparison to the m4 and other new 6Gbps drives we've tested.
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). I perform three concurrent IOs and run the test for 3 minutes. The results reported are in average MB/s over the entire time. We use both standard pseudo randomly generated data for each write as well as fully random data to show you both the maximum and minimum performance offered by SandForce based drives in these tests. The average performance of SF drives will likely be somewhere in between the two values for each drive you see in the graphs. For an understanding of why this matters, read our original SandForce article.
If there's one thing Crucial focused on with the m4 it's random write speeds. The 256GB m4 is our new king of the hill when it comes to random write performance. It's actually faster than a Vertex 3 when writing highly compressible data. It doesn't matter if I run our random write test for 3 minutes or an hour, the performance over 6Gbps is still over 200MB/s.
Let's look at average write latency during this 3 minute run:
On average it takes Crucial 0.06ms to complete three 4KB writes spread out over an 8GB LBA space. The original C300 was pretty fast here already at 0.07ms—it's clear that these two drives are very closely related. Note that OCZ's Vertex 3 has a similar average latency but it's not actually writing most of the data to NAND—remember this is highly compressible data, most of it never hits NAND.
Now let's look at max latency during this same 3 minute period:
You'll notice a huge increase in max latency compared to average latency, that's because this is when a lot of drives do some real-time garbage collection. If you don't periodically clean up your writes you'll end up increasing max latency significantly. You'll notice that even the Vertex 3 with SandForce's controller has a pretty high max latency in comparison to its average latency. This is where the best controllers do their work. However not all OSes deal with this occasional high latency blip all that well. I've noticed that OS X in particular doesn't handle unexpectedly high write latencies very well, usually resulting in you having to force-quit an application.
Note the extremely low max latency of the m4 here: 4.3ms. Either the m4 is ultra quick at running through its garbage collection routines or it's putting off some of the work until later. I couldn't get a clear answer from Crucial on this one, but I suspect it's the latter. I'm going to break the standard SSD review mold here for a second and take you through our TRIM investigation. Here's what a clean sequential pass looks like on the m4:
Average read speeds are nearing 400MB/s, average write speed is 240MB/s. The fluctuating max write speed indicates some clean up work is being done during the sequential write process. Now let's fill the drive with data, then write randomly across all LBAs at a queue depth of 32 for 20 minutes and run another HDTach pass:
Ugh. This graph looks a lot like what we saw with the C300. Without TRIM the m4 can degrade to a very, very low performance state. Windows 7's Resource Monitor even reported instantaneous write speeds as low as 2MB/s. The good news is the performance curve trends upward: the m4 is trying to clean up its performance. Write sequentially to the drive and its performance should start to recover. The bad news is that Crucial appears to be putting off this garbage collection work a bit too late. Remember that the trick to NAND management is balancing wear leveling with write amplification. Clean blocks too quickly and you burn through program/erase cycles. Clean them too late and you risk high write amplification (and reduced performance). Each controller manufacturer decides the best balance for its SSD. Typically the best controllers do a lot of intelligent write combining and organization early on and delay cleaning as much as possible. The C300 and m4 both appear to push the limits of delayed block cleaning however. Based on the very low max random write latencies from above I'd say that Crucial is likely doing most of the heavy block cleaning during sequential writes and not during random writes. Note that in this tortured state—max write random latencies can reach as high as 1.4 seconds.
Here's a comparison of the same torture test run on Intel's SSD 320:
The 320 definitely suffers, just not as bad as the m4. Remember the higher max write latencies from above? I'm guessing that's why. Intel seems to be doing more cleanup along the way.
And just to calm all fears—if we do a full TRIM of the entire drive performance goes back to normal on the m4:
What does all of this mean? It means that it's physically possible for the m4, if hammered with a particularly gruesome workload (or a mostly naughty workload for a longer period of time), to end up in a pretty poor performance state. I had the same complaint about the C300 if you'll remember from last year. If you're running an OS without TRIM support, then the m4 is a definite pass. Even with TRIM enabled and a sufficiently random workload, you'll want to skip the m4 as well.
I suspect for most desktop workloads this worst case scenario won't be a problem and with TRIM the drive's behavior over the long run should be kept in check. Crucial still seems to put off garbage collection longer than most SSDs I've played with, and I'm not sure that's necessarily the best decision.
Forgive the detour, now let's get back to the rest of the data.
Many of you have asked for random write performance at higher queue depths. What I have below is our 4KB random write test performed at a queue depth of 32 instead of 3. While the vast majority of desktop usage models experience queue depths of 0—5, higher depths are possible in heavy I/O (and multi-user) workloads:
High queue depth 4KB random write numbers continue to be very impressive, although here the Vertex 3 actually jumps ahead of the m4.
Random read performance is actually lower than on the C300. Crucial indicated that it reduced random read performance in favor of increasing sequential read performance on the m4. We'll see what this does to real world performance shortly.
Facebook
Twitter
RSS
103 Comments
View All Comments
killless - Friday, April 1, 2011 - link
I frequently use VMWare at work.One of the tasks that takes forever is deleting VMWare snapshots. Or even worse one is shrinking VMWare disk foot print. In both of these cases 95% is spent on disk read/write. They take from minutes to hours. They mix random and sequential access.
More that that they are fairly repeatable...
Using Kingstone SSDNow instead of harddisk made a huge impact - it is about 3 times faster. However it still takes 2 hours sometimes to shrink disk.
I think that would be a good repeatable set of tests.
CrustyJuggler - Saturday, April 2, 2011 - link
I just bought a spanking 15" MacBook Pro which i know supports Intels new Sandybridge and the sata6gb interface. I decided to buy with just the stock HDD which i will move to the optical bay after purchasing one of these new spangly SSDsAfter reading just about every review i'm still non the wiser as to which drive would benefit me the most so I think in conclusion i will wait for the leading drives to be released. The OCZ is always favourable in the benchmarks but the horror stories of reliability coupled with dreadful customer support make me nervous.
The intel 510 seems to have great support and reliability but poor performance.
I've heard little to nothing about Corsair's ForceGT which should be somewhere in the realms Vertex 3 performance right?
I'm happy to wait at least another 8 weeks i think and just hope more reviews and testing shows up in that time.. I was using a Force F60 on the laptop i replaced and I had no problems whatsoever so i hope Corsair can have a timely release with the GT.
I had my eye on Crucial's M4 for a while now but these latest crop of reviews have left me pondering even more. Trim is not supported on Mac as of yet so Anand's take on the M4 makes alarm bells ring regarding trim
First time poster long time reader, but not very tech savvy so what do to folks?
Shark321 - Sunday, April 3, 2011 - link
Anand is #1 at SSD reviews, but there still a long way to achieve perfection.On many workstations in my company we have a daily SSD usage of at least 20 GB, and this is not something really exceptional.
One hibernation in the evening writes 8 GB (the amount of RAM) to the SSDs. And no, Windows does not write only the used RAM, but the whole 8 GB. One of the features of Windows 8 will be that Windows does not write the whole RAM content when hibernating anymore. Windows 7 disables hibernation by default on system with >4GB of RAM for that very reason!
Several of the workstation use RAM-Disks, which write a 2 or 3 GB Images on Shutdown/Hibernate.
Since we use VMWare heavily, 1-2 GB is written contanstly all over the day as Spanshots. Add some backup spanshops of Visual Studio products to that and you have another 2 GB.
Writing 20 GB a day, is nothing unusual, and this happens on at least 30 workstations. Some may even go to 30-40 GB.
From all the SSDs we have used over the years, there was about 10% failure rate within 2 years, so daily backups are really necessary. When doing a backup of a SSD to a HDD with True Image, the performance of the individual SSDs differs a lot.
So future benchmarks for professional users should take into consideration:
- a daily usage of at least 20 GB (better 40 GB)
- benchmarking VMWare creating snapshots and shringing images
- unpacking of large ISO images
- hibernate peformance
- backup performance
Thanks!
789427 - Monday, April 4, 2011 - link
Anand, can't you design a power measurement benchmark whereby typical disc activity is replicated.e.g. Power consumption while video encoding (the time taken shouldn't vary by more than 10% - you could add in the difference in idle power consumption as well!
Or... copying 100 different 1 Mb sections at 1 sec intervals of a 20 min media file - Mp3, divx mkv
My point is that Sure, SSD's make your system use more power in most benchmarks because the system is asked to do more. Ask the system to do the same thing over the same period and measure power consumption.
cb
gunslinger690 - Tuesday, April 5, 2011 - link
Ok all I really care about on the machine I'm considering using this on is gaming and web surfing. That's all I care about. Is this a good drive for this sort of app.VJ - Thursday, April 7, 2011 - link
"I've already established that 3000 cycles is more than enough for a desktop workload with a reasonably smart controller."You haven't "established" much unless you take the free space into consideration. Many desktop users will not have 100GB free space on their drives and with 20GB free space and a write amplification of 10x, the lifetime of a drive may drop to a couple of years.
A 3D plot of the expected lifetime as a function of available free space (10GB-100GB) and write amplification (1x-20x) would make your argument more sound and complete.
Hrel - Saturday, April 16, 2011 - link
I'd really like to know if using a SSD actually has any real world impact. I mean, benchmarks are great. But come on, it's not gonna make me browse the internet any fast or get me higher FPS in Mass Effect; so what's the point? Really, the question comes down to why should I go out and buy two 2TB hard drives, RAID them then ALSO buy an SSD to install the OS on? So windows boots in 7 seconds instead of 27? Cause quite frankly if it's gonna cost me an extra 120-240 dollars I'll just wait 20 seconds. I almost never boot my machine from scratch anyway.Ideally I'd want to use a machine with an SSD in it before buying one. But since that doesn't seem likely I'd love it if you guys could just point a camera at two machines right next to eachother, boot them up, wait for both to finish loading the OS. Then use them. Go online, read some anandtech, boot up Word and type something, open photoshop and edit a picture then start up a game and play for a couple minutes. Cause I'm willing to bet, with the exception of load times, there will be no difference at all. And like I already said, if my game takes 20 seconds to load instead of 5, I can live with that. It's not worth anywhere near 100+ dollars.
Just to be clear one should have an SSD in it near to the 100 dollar mark, since that's as expensive of an SSD most people can even afford to consider. And the other should have two modern 7200rpm mechanical disks from WD in a striped RAID.
Hrel - Saturday, April 16, 2011 - link
both on 6GBPS on P67.Hrel - Saturday, April 16, 2011 - link
forgot to mention, the SSD machine should also have the same 2 mechanical disks in striped RAID and all the games and programs should be installed on those. Cause for 100 dollars the only thing you can put on an SSD is the OS and some small programs like the browser and various other things every PC needs to be usable; maybe photoshop too but the photos couldn't be on the SSD.Hrel - Saturday, April 16, 2011 - link
the games can't be installed on the SSD is my point.