The Crucial m4 (Micron C400) SSD Review
by Anand Lal Shimpi on March 31, 2011 3:16 AM ESTLast week I was in Orlando attending CTIA. While enjoying the Florida weather, two SSDs arrived at my office back in NC: Intel's SSD 320, which we just reviewed three days ago and Crucial's m4. Many of you noticed that I had snuck in m4 results in our 320 review but I saved any analysis/conclusions about the drive for its own review.
There are more drives that I've been testing that are missing their own full reviews. Corsair's Performance Series 3 has been in the lab for weeks now, as has Samsung's SSD 470. I'll be talking about both of those in greater detail in an upcoming article as well.
And for those of you asking about my thoughts on the recent OCZ related stuff that has been making the rounds, expect to see all of that addressed in our review of the final Vertex 3. OCZ missed its original March release timeframe for the Vertex 3 in order to fix some last minute bugs with a new firmware revision, so we should be seeing drives hit the market shortly.
There's a lot happening in the SSD space right now. All of the high end manufacturers have put forward their next-generation controllers. With all of the cards on the table it's clear that SandForce is the performance winner once again this round. So far nothing has been able to beat the SF-2200, although some came close—particularly if you're still using a 3Gbps SATA controller.
All isn't lost for competing drives however. While SandForce may be the unequivocal performance leader, compatibility and reliability are both unknowns. SandForce is still a very small company with limited resources. Although validation has apparently improved tremendously since the SF-1200 last year, it takes a while to develop a proven track record. As a result, some users and corporations feel more comfortable buying from non-SF based competitors—although the SF-2200 may do a lot to change some minds once it starts shipping.
The balance of price, performance and reliability is what keeps this market interesting. Do you potentially sacrifice reliability for performance? Or give up some performance for reliability? Or give up one for price? It's even tougher to decide when you take into account that all of the players involved have had major firmware bugs. Even though Intel appears to have the lowest return rate out of all of the drives it's not excluded from the reliability/compatibility debate.
Crucial's m4, Micron's C400
Micron and Intel have a joint venture, IMFT, that produces NAND Flash for both companies as well as their customers. Micron gets 51% of IMFT production for its own use and resale, while Intel gets the remaining 49%.
Micron is mostly a chip and OEM brand, Crucial is its consumer memory/storage arm. Both divisions shipped an SSD called the C300 last year. It was the first 6Gbps SATA SSD we tested and while it posted some great numbers, the drive launched to a very bumpy start.
| Crucial's m4 Lineup | ||||||||||||||
| CT064M4SSD2 | CT128M4SSD2 | CT256M4SSD2 | CT512M4SSD2 | |||||||||||
| User Capacity | 59.6GiB | 119.2GiB | 238.4GiB | 476.8GiB | ||||||||||
| Random Read Performance | 40K IOPS | 40K IOPS | 40K IOPS | 40K IOPS | ||||||||||
| Random Write Performance | 20K IOPS | 35K IOPS | 50K IOPS | 50K IOPS | ||||||||||
| Sequential Read Performance | Up to 415MB/s | Up to 415MB/s | Up to 415MB/s | Up to 415MB/s | ||||||||||
| Sequential Write Performance | Up to 95MB/s | Up to 175MB/s | Up to 260MB/s | Up to 260MB/s | ||||||||||
A few firmware revisions later and the C300 was finally looking good from a reliability perspective. Although recently I have heard reports of performance issues with the latest 006 firmware, the drive has been working well for me thus far. It just goes to show you that company size alone isn't an indication of compatibility and reliability.
Crucial RealSSD C300 (back), Crucial m4 (front)
This time around Crucial wanted to differentiate its product from what was sold to OEMs. Drives sold by Micron will be branded C400 while consumer drives are called the m4. The two are the same, just with different names.
The Marvell 88SS9174-BLD2 in Crucial's m4
Under the hood, er, chassis we have virtually the same controller as the C300. The m4 uses an updated revision of the Marvell 9174 (BLD2 vs. BKK2). Crucial wouldn't go into details as to what was changed, just to say that there were no major architectural differences and it's just an evolution of the same controller used in the C300. When we get to the performance you'll see that Crucial's explanation carries weight. Performance isn't dramatically different from the C300, instead it looks like Crucial played around a bit with firmware. I do wonder if the new revision of the controller is at all less problematic than what was used in the C300. Granted fixing any old problems isn't a guarantee that new ones won't crop up either.
The 88SS9174-BKK2 is in the Intel SSD 510
The m4 is still an 8-channel design. Crucial believes it's important to hit capacities in multiples of 8 (64, 128, 256, 512GB). Crucial also told me that the m4's peak performance isn't limited by the number of channels branching off of the controller so the decision was easy. I am curious to understand why Intel seems to be the only manufacturer that has settled on a 10-channel configuration for its controller while everyone else picked 8-channels.
Crucial sent along a 256GB drive populated with sixteen 16GB 25nm Micron NAND devices. Micron rates its 25nm NAND at 3000 program/erase cycles. By comparison Intel's NAND, coming out of the same fab, is apparently rated at 5000 program/erase cycles. I asked Micron why there's a discrepancy and was told that the silicon's quality and reliability is fundamentally the same. It sounds like the only difference is in testing and validation methodology. In either case I've heard that most 25nm NAND can well exceed its rated program/erase cycles so it's a non-issue.
Furthermore, as we've demonstrated in the past, given a normal desktop usage model even NAND rated for only 3000 program/erase cycles will last for a very long time given a controller with good wear leveling.
Let's quickly do the math again. If you have a 100GB drive and you write 7GB per day you'll program every MLC NAND cell in the drive in just over 14 days—that's one cycle out of three thousand. Outside of SandForce controllers, most SSD controllers will have a write amplification factor greater than 1 in any workload. If we assume a constant write amplification of 20x (and perfect wear leveling) we're still talking about a useful NAND lifespan of almost 6 years. In practice, write amplification for desktop workloads is significantly lower than that.
Remember that the JEDEC spec states that once you've used up all of your rated program/erase cycles, the NAND has to keep your data safe for a year. So even in the unlikely event that you burn through all 3000 p/e cycles and let's assume for a moment that you have some uncharacteristically bad NAND that doesn't last for even one cycle beyond its rating, you should have a full year's worth of data retention left on the drive. By 2013 I'd conservatively estimate NAND to be priced at ~$0.92 per GB and in another three years beyond that you can expect high speed storage to be even cheaper. In short, combined with good ECC and an intelligent controller I wouldn't expect NAND longevity to be a concern at 25nm.
The m4 is currently scheduled for public availability on April 26 (coincidentally the same day I founded AnandTech fourteen years ago), pricing is still TBD. Back at CES Micron gave me a rough indication of pricing however I'm not sure if those prices are higher or lower than what the m4 will ship at. Owning part of a NAND fab obviously gives Micron pricing flexibility, however it also needs to maintain very high profit margins in order to keep said fab up and running (and investors happy).
The Test
| CPU |
Intel Core i7 965 running at 3.2GHz (Turbo & EIST Disabled) Intel Core i7 2600K running at 3.4GHz (Turbo & EIST Disabled)—for AT SB 2011, AS SSD & ATTO |
| Motherboard: |
Intel DX58SO (Intel X58) Intel H67 Motherboard |
| Chipset: |
Intel X58 + Marvell SATA 6Gbps PCIe Intel H67 |
| Chipset Drivers: |
Intel 9.1.1.1015 + Intel IMSM 8.9 Intel 9.1.1.1015 + Intel RST 10.2 |
| Memory: | Qimonda DDR3-1333 4 x 1GB (7-7-7-20) |
| Video Card: | eVGA GeForce GTX 285 |
| Video Drivers: | NVIDIA ForceWare 190.38 64-bit |
| Desktop Resolution: | 1920 x 1200 |
| OS: | Windows 7 x64 |
Facebook
Twitter
RSS
103 Comments
View All Comments
Rasterman - Friday, April 1, 2011 - link
LOL wait a year? You are nuts, a year from now there will be totally new products out at all new high prices. Prices come down? Most of these new drives are not even in full production yet and some aren't even released. Regardless upgrading from a G2 level drive to any of these you aren't going to see any difference in real word use, only if you are doing massive file transfers all of the time or can afford to blow money for minimal performance increases (work system) then there is absolutely no point in upgrading speed wise.eamon - Thursday, March 31, 2011 - link
The article states that "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." These statements don't really seem backed up by the data presented.Take the m4-is-bad-without-TRIM idea: If you lack TRIM *and* torture-test your SSD for twenty-minutes of random writes, then you'll see a significant but temporary loss of performance, is what you show. That's not ideal, but really, outside of benchmarking, 20-minutes of random write torture are exceedingly unusual. And you don't show a benchmark with TRIM support enabled (i.e., not just running on an OS with TRIM support, but running on a filesystem and where the filesystem isn't just completely filled up). Does the same performance degradation occur with normal TRIM usage patterns? That seems to be a far more likely usage pattern, but you don't test it.
This makes the second statement seem even less warranted - first of all, you're testing a very unusual access pattern, and you're doing it without a common feature (TRIM) designed to avoid this degradation, and you're not checking how long it takes for performance to recover (after all, if performance quickly recovers after torture testing, then it may well be reasonable to accept the low risk of low performance since the situation will rectify itself anyhow).
I'm not trying to defend the m4 here - and you might be right, but the data sure seems insufficient to draw these rather relevant conclusions. How quickly does the m4 recover, and how does TRIM impact the degradation in the first place?
JNo - Thursday, March 31, 2011 - link
+1I too am not trying to defend the m4 but I think a lot of emphasis is put on sequential performance reads & writes. Whilst I'm sure the everyone will copy/move very large files to their SSD occasionally, the vast majority will still have them as their boot drive where overall system responsiveness (random reads/writes) is still king. It's still a useful metric to know for those who really want to do video editing etc on an SSD but generally over stated.
For most users, like myself, I think the performance benefits of the amazing Vertex 3 will be imperceptible over the m4 99.999% of the time. So the real question, as always, is price - the Vertex 3 does justify a premium but only a small one. Most value-for-money buyers would probably get better real world value from the m4 assuming it is cheaper.
tno - Thursday, March 31, 2011 - link
I think the thing to remember is that this performance drop occurred during a pretty short torture test. But the possibility still exists that if the m4 delays garbage collection till a sequential write comes along, then the possibility could exist that the drive could suffer lots of insults from random writes, drastically decreasing performance, and, because not very many sequential writes are performed, the garbage collection never has a chance to remedy the situation.This is a hypothetical but it's not that far fetched for those of us that focus on using SSDs as OS drives. If you put a small OS drive in a desktop and supplement it with a large mechanical drive, your OS drive might not see a decently long sequential write for some time. Particularly if all your downloads and content generation goes to the mechanical drive.
Anand Lal Shimpi - Thursday, March 31, 2011 - link
For most users, over the course of several months, access patterns can begin to mimic portions of our torture test. I'll be addressing this in a future article but tasks like web browsing, system boot and even application launches are only sequential IOs for less than 50% of the time.I state that I doubt it'll be the case for typical desktop workloads but honestly there's no way to be sure given a short period of testing. Note that every recommended SSD we test ultimately goes into a primary use system and we subject it to a realistic workload for months, noting any issues that do crop up - which eventually gets fed back into our reviews.
Our data shows that in a perfect world, the m4 does quite well in most of the tests. My concerns are two fold:
1) Low max latency during random write operations seems to imply very little gc work is being done during typical random writes.
2) Our torture test shows that delayed garbage collection can result in a pretty poor performance scenario, where the m4 is allowed to to drop a bit lower than I'd like.
How likely is it that you'll encounter this poor performance state?
1) Without TRIM it's very likely. One of the machines I run daily is an OS X system without the TRIM hack enabled. Indilinx, the C300 and even Intel's X25-M both hit this worst case scenario performance level after a few months of use.
2) With TRIM it'll depend entirely based on your workload. Remember that you never TRIM the entire drive like we did (only in the case of a full format). Given a sufficiently random workload without enough consistent sequential writing to bring up performance, I could see things get this bad.
Again my point wasn't to conclude that the m4 was a bad drive, just that these are concerns of mine and I'd rather be cautious about them when recommending something to the public. It's no different than being cautious about recommending the Vertex 3 given unproven reliability and questionable track record.
Take care,
Anand
kmmatney - Thursday, March 31, 2011 - link
So, could someone write a tool that does a huge sequential write to restore performance? Sort of like running the Intel SSD Toolbox and manually doing a TRIM? I could live with that. I'm still running Windows XP at work.bobbozzo - Thursday, March 31, 2011 - link
Just copy a really big file from another drive.bobbozzo - Thursday, March 31, 2011 - link
Or a bunch of not as big files.7Enigma - Friday, April 1, 2011 - link
I'm quite certain I remember there being a program that does this created by an enthusiast way back during the first gen of SSD's.lyeoh - Friday, April 1, 2011 - link
To me I'm actually very happy about the low latency during random write (and read) ops.Can't there be a way to do garbage collection during idle time and not sacrifice latency?
Yes I know that the drive could think it's idle and then start garbage collection just at the very moment when the user finally decides to do something. But if you do the garbage collection at a low intensity, should it affect performance that much? I'm assuming that since the drives are fast they can do a fair bit of garbage collection during idle at say 10-20% speed and not affect the user experience much.
Enterprise drives might be busy all the time and total throughput often matters more than keeping latency in the milliseconds (it's still important but...), so the best time to do garbage collection for those drives would be ASAP.
But that's not true for Desktop drives. Right now as I'm typing in this post, my HDD isn't busy at all. So an SSD could do a fair bit of GC during that long pause. Same for when you are playing a game (after it has loaded the game assets).
It seems silly for Desktop SSDs to do GC during the time a user wants to do something (and presumably wants to get it done as fast as possible).
The Intel SSDs have a max latency of hundreds of milliseconds! That's very human noticeable! Do conventional nonfaulty HDDs even get that slow?