The Crucial/Micron M500 Review (960GB, 480GB, 240GB, 120GB)by Anand Lal Shimpi on April 9, 2013 9:59 AM EST
This is probably the most excited I've been about any SSD launch in quite a while. At CES this year, Crucial announced its M500 SSD - the world's first to use Micron's new 128Gbit MLC NAND die. Courtesy of the cost savings and density increase associated with this new 128Gbit NAND, the M500 would be available in a 960GB capacity, priced at $599. That works out to be around $0.62 per GB for a truly gigantic drive by today's standards. It's exciting. For the past five years I've been learning to live off of less storage that I thought I needed, but the M500 had the potential to spoil me once again.
The M500 starts out with a familiar refrain: a Marvell controller with custom firmware from Crucial/Micron and of course, Micron NAND. All of these parts get updated though, some in more interesting ways than others. The controller is now Marvell’s 88SS9187, an updated version of the 9174 used in the m4. The 9187 is a speed/feature bump over the 9174 and is also used in Plextor’s M5 Pro. I should note that this time around both the Crucial (end user) and Micron (OEM) drives will feature the same M500 branding.
One of the benefits of Marvell’s 9187 is the support for DDR3 memory, which we see exercised on the M500. In its largest configuration, the M500 features 1GB of DDR3-1600. Crucial claims only 2 - 4MB of user data ever ends up in this DRAM, the overwhelming majority of the DRAM is used to cache the page/indirection table that maps logical block addresses to pages in NAND. Like most SSD makers, Crucial won’t talk about the structure of its mapping table but given the size of the DRAM I think it’s safe to assume that we’re looking at a relatively flat structure that should be easy to manage (more on this later).
|Crucial / Micron M500 Specifications|
|NAND||Micron 20nm 2bpc MLC NAND (128Gbit die)|
|Form Factor||2.5" 7mm/9.5mm, mSATA, M.2||2.5" 7mm/9.5mm, mSATA, M.2||2.5" 7mm/9.5mm, mSATA, M.2||2.5" 7mm/9.5mm|
|4KB Random Read||
|4KB Random Write||
|Drive Lifetime||72TB Writes (90% full, 25/75% sequential/random IO - 50% 4KB, 40% 64KB, 10% 128KB)|
While the M500’s controller is nothing new, its NAND is. The M500 is the first drive to ship with the latest version of IMFT’s 20nm MLC NAND, featuring 128Gbit die. All previous NAND devices from IMFT (as well as its competitors) top out at 64Gbit (8GB) per 2-bit MLC NAND die. The move to larger die decreases the number of die/devices needed to hit each capacity point, and it also makes 1TB SSDs cost effective for the first time ever.
The cost savings come from the fact that these 128Gbit die aren’t simple doublings of last year’s 64Gbit devices; they include a few changes. The most prominent is a shift in page size from 8KB to 16KB. Larger page sizes are more desirable to implement at smaller NAND geometries, which is why you normally see these page size transitions with major shifts in process technology (e.g. 4KB to 8KB page size transition back at 25nm). The good news is that larger page sizes increase sequential throughput, but at the expense of latency. Given that NAND program times increase with smaller NAND geometries, once again the deck is stacked against manufacturers looking to increase performance as they exploit the benefits of Moore’s Law.
The other big change with the 128Gbit implementation of IMFT’s 20nm process is the inclusion of ONFI 3.0 support. There are some power savings courtesy of ONFI 3.0 (lower voltages, on-die termination), but the big news here is an increase in max interface speed. The previous ONFI interface standard (2.x) topped out at around 200MB/s, while ONFI 3.0 kicks that up to 400MB/s. Crucial’s implementation seems to be limited to around 330MB/s, but the drive isn’t anywhere close to saturating that. Remember the interface speed governs the maximum rate at which you can transfer data to/from a NAND device. Most NAND devices are capable of dual-channel operation so in the higher capacity implementations we’re talking about a maximum NAND-to-controller transfer rate of over 600MB/s. There’s more than enough headroom here.
Supporting the new controller, new NAND die, larger page sizes and ONFI 3.0 obviously require a new firmware, so the M500 ships with an evolution of what Crucial developed for the m4. The end result is vastly improved performance across the board, the big question being how well does it compare to the rest of the world given how much has changed since the m4 first arrived on the market.
The 20nm 128Gbit NAND: Larger Pages, Larger Blocks, Lower Performance & Cost?
|Intel/Micron NAND Evolution|
|Single Die Max Capacity||16Gbit||32Gbit||64Gbit||64Gbit||128Gbit|
|Pages per Block||128||128||256||256||512|
|Read Page (max)||-||-||75 µs||100 µs||115 µs|
|Program Page (typical)||900 µs||1200 µs||1300 µs||1300 µs||1600 µs|
|Erase Block (typical)||-||-||3 ms||3 ms||3.8 ms|
|Gbit per mm2||-||0.186||0.383||0.542||0.634|
|Rated Program/Erase Cycles||10000||5000||3000||3000||3000|
There's a lot of data in the table above, but if you look closely you'll see a couple of trends. The obvious ones are increasing page and block size over time. NAND program latency has also climbed steadily over the years, while endurance decreased. All in all, the picture looks pretty bleak. It's impressive that performance keeps going up each generation given how much the deck is stacked against seeing continued performance improvements. The increase in program time gives you a preview of what we're going to see in the performance pages. Small writes will take longer. Garbage collection routines on a full drive will also take longer to run as each block that needs to be recycled for use has more pages and more data to deal with. Although Crucial uses a faster controller in the M500 vs. m4, the internal housekeeping it has to do goes up tremendously as well. The M500 isn't a drive that was built in pursuit of peak performance. Instead this drive targets the mainstream.
Looking at the difference in density between the two 20nm NAND devices, there's nearly a 17% increase in density from moving to the larger page/block sizes. It's a remarkable improvement especially when you consider the gains are decoupled from a new process node. Ultimately this is Micron's answer to TLC for the time being. Rather than sacrificing endurance to get to lower price points, the 20nm 128Gbit 2bpc MLC NAND device at mature yields should deliver competitive pricing at higher endurance. Indeed this is the message behind Crucial's M500. The company isn't targeting Samsung's SSD 840 Pro, but rather the TLC based 840.
|Crucial M500||$129 ($129)||$219 ($202)||$399 ($442)||$599 ($570)|
|Intel SSD 335||$181||$220||-||-|
|Samsung SSD 840||$100||$169||$333||-|
|Samsung SSD 840 Pro||$139||$229||$463||-|
The reality of it all is the M500's MSRPs are closer to the 840 Pro's street prices than the 840's. MSRPs tend to run a bit high on SSDs, so I wouldn't be too surprised to see the M500 eventually settle down closer to the 840 (remember the MSRP for the 840/840 Pro at 250/256GB are $199 and $269, respectively). It's definitely a different approach to driving costs down vs. going to TLC, and it's one that can't necessarily be repeated each generation, but for now the answer works. I'm not sure how meaningful the added endurance is for most client users, although you could make an interesting case for the M500 in some enterprise workloads that the TLC 840 wouldn't be able to make it into.
The big news is of course the 960GB capacity point. At $599 the 960GB M500 is by far the cheapest drive available at anywhere that capacity. A quick search on Newegg reveals a $1000 Mushkin 960GB drive and a $3000 1TB OCZ Octane. At $599, the 960GB is a steal at $0.62/GB. Even the Phison based 960GB BP4 from MyDigitalSSD weighs in at $799, and OWC's Mercury Electra MAX (3Gbps SATA) is still over $1000. To put the drive's excellent price in perspective, the 960GB M500 has roughly the same MSRP as Intel's 80GB X25-M had back in 2008. That's an order of magnitude more storage capacity at the same price in 5 years time. Moore's Law makes me happy.
Post Your CommentPlease log in or sign up to comment.
View All Comments
mayankleoboy1 - Wednesday, April 10, 2013 - linkthanks! These look much better, and more realworld+consumer usage.
metafor - Wednesday, April 10, 2013 - linkI'd be very interested to see an endurance test for this drive and how it compares to the TLC Samsung drives. One of the bigger selling points of 2-level MLC is that it has a much longer lifespan, isn't it?
73mpl4R - Wednesday, April 10, 2013 - linkThank you for a great review. If this is a product that paves the way for better drives with 128Gbit dies, then this is most welcome. Interesting with the encryption aswell, gonna check it out.
raclimja - Wednesday, April 10, 2013 - linkpower consumption is through the roof.
very disappointed with it.
toyotabedzrock - Wednesday, April 10, 2013 - linkIf you wrote 1.5 TB of data for this test then you used 2% of the drives write life in 10-11 hours.
As a heavy multitasker this worries me greatly. Especially if you edit large video files.
Solid State Brain - Wednesday, April 10, 2013 - linkAs I written in one of the comments above, they probably state 72 TiB of maximum supported writes for liability and commercial reasons. They don't want users to be using these as enterprise/professional drives (and chances are that if you write more than 40 GiB/day continuously for 5 years you're not a normal consumer). Most people barely write 1.5 TiB in 6 months of use anyway. So even if 72 TiB don't seem much, they're actually quite a lot of writes.
Taking into account drive and NAND specifications, and an average write amplification of 2.0x (although in case of sequential workloads such as video editing this should be much closer to 1.0x), a realistic estimate as a minimum drive endurance would be:
120 GB => 187.5 TiB
240 GB => 375.0 TiB
480 GB => 750.0 TiB
960 GB => 1.46 PiB
Of course, it's not that these drives will stop working after 3000 write cycles. They will go on as long as uncorrectable write errors (which increase as the drive gets used) remain within usable margins.
glugglug - Wednesday, April 10, 2013 - linkIt is very easy to come up with use cases where a "normal" user will end up hitting the 72TB of writes quickly.
Most obvious example is a user who is using this large SSD to transition from a large HDD without it being "just a boot drive", so they archive a lot of stuff.
Depending on MSSE settings, it will likely uncompress everything into C:\Windows\Temp when it does scans each night scan.
You don't want to know how much of my X-25M G1's lifespan I killed in about 6 months time before finding out about that and junctioning my temp directories off of the SSD.
Solid State Brain - Wednesday, April 10, 2013 - linkI am currently using a Samsung 840 250GB with TLC memory, without any hard disk installed in my system. I use it for everything from temp files to virtual machines to torrents. I even reinstalled the entire system a few times because I hopped between Linux and Windows "just because". I haven't performed any "SSD optimization" either. A purely plug&play usage, and it isn't a "boot drive" either. Furthermore, my system is always on. Not quite a normal usage I'd say.
In 47 days of usage I've written 2.12 TiB and used 10 write cycles out of 1000. This translates in 13 years of drive life at my current usage rate.
My usage graph + SMART data:
Temp directories alone aren't going to kill your SSD, not directly at least. It likely was something caused by some anomalous write-happy application, not Windows by itself.
juhatus - Wednesday, April 10, 2013 - linkWhat would you recommend overprovisioning for 256Gb M4 with bitlocker, 10-15-25% ? Also what was the M4's firmware you used to compare to M500? Also are there any benefits for M500 with bitlocker on windows 7? thanks for review, please add 25% results for M4 too :)
Solid State Brain - Wednesday, April 10, 2013 - linkIncreasing overprovisioning is only going to matter when continuously writing to the drive without never (or rarely) executing a TRIM operation every time an amount of data roughly equivalent (in practice, less, depending on workload and drive conditions) to the amount of free space gets written.
This almost never happens in real life usage by the target userbase of such a drive. It's a matter for servers, for those who for a reason or another (like hi-definition video editing) perform many sustained writes, or for those working in an environment without TRIM support (which isn't the case for Windows 7/8, although it can be for MacOS or Linux - where it has to be manually enabled).
Anandtech SSD benchmarks aren't very realistic for most users, and the same can be said for their OP reccomendations.