The Crucial m4 SSD Update: Faster with FW0009
by Anand Lal Shimpi on August 31, 2011 12:56 AM ESTTesting TRIM
SSDs by default have no knowledge of what locations in NAND contain valid or invalid data. All writes are committed to NAND and it's not until an LBA is overwritten that the controller gets rid of the data previously at that address. Well designed controllers thrive with as much free space as possible, but without knowing what NAND blocks contain valid data the amount of free space on a drive from the controller's perspective diminishes over time. This results in the oh-so-familiar performance degradation over time that plagues all SSDs. The ATA TRIM command was introduced to help alleviate this issue. In a supported OS with TRIM enabled drivers, whenever data is deleted a command is sent to the SSD to TRIM the LBAs that map to the now invalid data. Upon receiving this command, modern SSDs mark those NAND blocks as invalid and schedule them for recycling. In the end this helps performance remain high over time.
Note that TRIM doesn't solve all fragmentation - you need a good controller with well architected firmware to ensure that fragmentation doesn't become an out of control problem. To understand how the m4's TRIM implementation performs let's first look at its fresh, out-of-box sequential write speed:
Note the relatively consistent write performance averaging 250MB/s. Now let's put the drive in a horribly fragmented state by first writing to all user addressable LBAs sequentially then performing a 4KB random write test at a queue depth of 32 across the entire drive for 20 minutes. This is what a sequential pass looks like after our little torture session:
Note the remarkable falloff in performance. Most of this is due to just how fast the m4 can write 4KB of data randomly across the drive, but it also shows that Crucial manages to reach such high 4KB random write speeds by not adequately combating fragmentation on the fly. Thankfully the drive does seem to recover pretty well, here's what it looks like after a second sequential pass:
Finally if we format the entire drive we get to see how well the m4 responds to the ATA TRIM command. To avoid giving the m4 an easier time I secure erased the drive, re-ran our torture test without the second pass (above) and then TRIMed its contents to produce the graph below:
Performance is back to new. What does all of this tell us? If you're running an OS with TRIM support you'll likely be just fine with the m4. Pseudo-random writes are common within any desktop workload, but if you avoid filling your drive to capacity and have a TRIM supported OS the drive shouldn't get into a bad state. The bigger concern is running the m4 in an OS without official TRIM support (e.g. Mac OS X) where you could find yourself in a particularly bad situation over a long period of time. Even then, it's obvious that sequential write passes over used LBAs cleans the drive up fairly well. Chances are that a standard desktop workload in a TRIM-free OS would be fine over the long run. If not, some sequential writes to any free space would do the trick (e.g. copying a large video file then deleting it).
Facebook
Twitter
RSS
45 Comments
View All Comments
Nakecat - Wednesday, August 31, 2011 - link
so if TRIM won't work in RAID, it's still ok to run in RAID with ssd built-in GC?I have 4 C300 256GB and thinking either going for RAID 0 or RAID 5.
jwilliams4200 - Wednesday, August 31, 2011 - link
It is NOT true that the Sandforce GC is notably better than the Crucial/Marvell GC.Anand has a terrible method of trying to measure the GC effectiveness. Running HD Tach is just an absurd way to look at how GC performs under realistic work loads. It is almost impossible to name a realistic workload that does large sequential writes OF A STREAM OF ZEROS across the entire span of the SSD. The Sandforce drives just compress the stream of zeros by a factor of about 10, and therefore need to write only about 10% as much data to flash as the Crucial/Marvell, thus making it look like the performance with Sandforce does not degrade much. But if you wrote the same workload to the SSD with incompressible data, the Sandforce GC performs similarly to the Crucial/Marvell GC.
This problem with Anand's testing has been pointed out to him before, but he continues to print misleading information.
Anyone who is interested in looking at sustained performance of SSDs without TRIM should look at the industry standard test protocols as defined in the SNIA documents for "Solid State Storage (SSS) Performance Test Specification (PTS)"
http://www.snia.org/tech_activities/standards/curr...
In particular, the is a pre-conditioning test that specifies using random data and 4KB random writes to get the drive into a steady-state condition. By measuring IOPS vs time while doing 4KB random writes, it is possible to observe the degradation in performance. Then after the drive reaches steady-state, more extensive tests are run to determine sustained performance. This is the sort of testing that Anand should be doing.
MarcHFR - Thursday, September 1, 2011 - link
I agree that using HD Tach is not a very good for such a thing on SandForce SSD.You can also note that HD Tach doesn't wrote so much data on the drive, even a "long" run is ratter quick.
Using IOMETER with incompressible data i get a onther story :
http://www.behardware.com/articles/830-13/tenue-pe...
aferox - Wednesday, August 31, 2011 - link
I've been running two C300 drives for about a year, and an m4 for about two months. Absolutely no problems in that time. Given that these drives were substantially (!) cheaper than the alternatives, and available in large capacities (total of 1TB) I've got to consider them excellent purchases. I'm definitely willing to give up a little speed for reliable and less expensive drives.danjw - Wednesday, August 31, 2011 - link
Why do you let us know that the some of the others are attached to a 6Gbps port, but not some. This chart and review are not useful, unless you provide that data. This seems like a no brainier. Are you purposely handicapping the drives that aren't attached to 6Gbps ports? What is the motivation for this?MrSpadge - Wednesday, August 31, 2011 - link
Considering it's called "Vertex 3 MAX IOPS 6Gbps (240GB)" it looks like a simply typo and was meant to be "Vertex 3 MAX IOPS 240GB (6Gbps)"... which is supported by the fact that the Vertex 3 pushes > 500 MB/s in the article, which would be impossible using SATA-2. The Samsung doesn't support SATA-3. Chill, mate.LTG - Wednesday, August 31, 2011 - link
On OSX (Mac) how much of a performance penalty do we pay over time for not having trim?You mentioned this may be an issue in a previous article...
LTG - Wednesday, August 31, 2011 - link
Ugh, sorry I saw you addressed that - thanks.ChristophWeber - Wednesday, August 31, 2011 - link
On my Intel X25M G2 practically none. There is a TRIM enabler tool for MacOSX floating around, ask Google.gramboh - Wednesday, August 31, 2011 - link
The 256gb M4 is still $439.99 at my local retailer/etailer, and $399.99 at newegg.ca - hopefully the price comes down a bit to match what it is going for in the U.S., because it is an excellent value compared to the 510 at those prices.