The Crucial/Micron M500 Review (960GB, 480GB, 240GB, 120GB)
by Anand Lal Shimpi on April 9, 2013 9:59 AM ESTPower Consumption
The M500 supports the new Device Sleep standard which will see platform support with Haswell this year. Crucial claims DIPM enabled idle power as low as 80mW, however even with DIPM enabled on our testbed we weren't able to get anything south of ~1W at idle. I'm digging to see if this is a M500 issue or one specific to our testbed, but Crucial is confident that in a notebook you'd see very little idle power consumption with the M500. Supporting DevSleep is important as that'll quickly become a must have feature for Haswell notebooks.
Load power looks excellent, which gives me hope that Crucial's idle power is indeed as good as they claim. The M500 is a direct competitor to Samsung's SSD 840 Pro when it comes to power consumption under load. Given how power efficient the 840 Pro is, the M500 is in good company.
Facebook
Twitter
RSS
111 Comments
View All Comments
NCM - Tuesday, April 9, 2013 - link
TRIM support is built into the OS X, but disabled by default for non-Apple drives. As others have pointed out, the freeware utility 'TRIM Enabler' easily takes care of that. The only other thing to know is that some OS X updates may reset TRIM to 'off', so it's as well to check after any update and re-enable it if necessary.I take care of an office full of Macs, including Mac Pros, iMacs, Minis and MacBook Pros, the majority of which have SSDs that I installed. I'm typing this on my 2010 MBP with a 512GB Plextor M3P.
With the price of SSDs now this is a very worthwhile upgrade, and particularly one that offers a new lease on life for older computers.
Bkord123 - Tuesday, April 9, 2013 - link
All of these comments are going to make my wife mad when I buy yet another gadget! I'm not as worried now about the TRIM issue. Btw, does this site have a page that ranks hard drives? I did look and didn't see anything here.jamyryals - Tuesday, April 9, 2013 - link
Anand has a Bench utility you can use to compare devices. Here's two popular reliable drives -http://www.anandtech.com/bench/Product/792?vs=743
glugglug - Tuesday, April 9, 2013 - link
With most SSDs no longer using 4KB pages, does it make sense to have 8KB and 16KB random write tests?Also, does application performance improve if the drives are formatted with an 8KB or 16KB cluster size?
Kristian Vättö - Tuesday, April 9, 2013 - link
Most real world IOs are 4KB.glugglug - Tuesday, April 9, 2013 - link
Not true, even with the default 4KB cluster size the drives get formatted with. If you format with 16KB clusters, *none* of the IOs will be 4KB.Kristian Vättö - Tuesday, April 9, 2013 - link
Based on the workloads we've traced (using default cluster size), 4KB is the most common IO size, although it obviously varies and some workloads may have consist of larger IO sizes. Do you have something that backs up your statement? Would be interesting to see that.glugglug - Tuesday, April 9, 2013 - link
According to the table in the article, for the Anandtech 2011 Heavy Workload, 28% of the IOs are 4KB, not "most".I am thinking that what must happen for a 4KB IO on a drive with 16KB pages is that it has to read the current contents of the 16KB page so that the 4KB being rewritten can be merged into it, then write a 16KB page, so each write really ends up being a read + write operation not just the write by itself.
Worse, when TRIM is used, if the TRIM operation covers only 4KB of the 16KB page, the page can't really be trimmed, because the other 12KB might still be in use; the drive firmware can't know for certain, so having a cluster size match or exceed the drive's page might result in better steady state performance over time because of TRIM not losing track of partial pages.
Tjalve - Wednesday, April 10, 2013 - link
I think there are some caching involved when dealing with writes thats smaller then the page size of the NAND. I would guss that the M500 caches in DRAM. There are other vendors that use the onboard flash for caching. Like Sandisk nCache for example.glugglug - Wednesday, April 10, 2013 - link
For some SSDs that is definately the case. I'm pretty sure Sandforce needed to do it for example, both because the compression makes the size of the flash writes unpredictable, and because if you look at the cluster sizes the chipset supports to go with various obscure controllers its kind of nuts.I don't think that is the case here though, because if you multiple the marketed 4KB random write numbers by 4KB, you pretty much get exactly the sequential write speed, and write-back caching to deal with the smaller writes would result in much better sequential performance.