Last 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

 

Random 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.

Sequential Read/Write Speed

To measure sequential performance I ran a 1 minute long 128KB sequential test over the entire span of the drive at a queue depth of 1. The results reported are in average MB/s over the entire test length.

Sequential write performance at low queue depths is good, but not quite as high as the 510 or Vertex 3

Sequential read speed is definitely down from the C300, despite Crucial's claim that random read performance was sacrificed to improve sequential read performance. The m4 so far appears to have better write performance at the sacrifice of read speed. There's much more than meets the eye, let's dig deeper.

AnandTech Storage Bench 2011: Much Heavier

I didn't expect to have to debut this so soon, but I've been working on updated benchmarks for 2011. Last year we introduced our AnandTech Storage Bench, a suite of benchmarks that took traces of real OS/application usage and played them back in a repeatable manner. I assembled the traces myself out of frustration with the majority of what we have today in terms of SSD benchmarks.

Although the AnandTech Storage Bench tests did a good job of characterizing SSD performance, they weren't stressful enough. All of the tests performed less than 10GB of reads/writes and typically involved only 4GB of writes specifically. That's not even enough exceed the spare area on most SSDs. Most canned SSD benchmarks don't even come close to writing a single gigabyte of data, but that doesn't mean that simply writing 4GB is acceptable.

Originally I kept the benchmarks short enough that they wouldn't be a burden to run (~30 minutes) but long enough that they were representative of what a power user might do with their system.

Not too long ago I tweeted that I had created what I referred to as the Mother of All SSD Benchmarks (MOASB). Rather than only writing 4GB of data to the drive, this benchmark writes 106.32GB. It's the load you'd put on a drive after nearly two weeks of constant usage. And it takes a *long* time to run.

I'll be sharing the full details of the benchmark in some upcoming SSD articles but here are some details:

1) The MOASB, officially called AnandTech Storage Bench 2011—Heavy Workload, mainly focuses on the times when your I/O activity is the highest. There is a lot of downloading and application installing that happens during the course of this test. My thinking was that it's during application installs, file copies, downloading and multitasking with all of this that you can really notice performance differences between drives.

2) I tried to cover as many bases as possible with the software I incorporated into this test. There's a lot of photo editing in Photoshop, HTML editing in Dreamweaver, web browsing, game playing/level loading (Starcraft II & WoW are both a part of the test) as well as general use stuff (application installing, virus scanning). I included a large amount of email downloading, document creation and editing as well. To top it all off I even use Visual Studio 2008 to build Chromium during the test.

Update: As promised, some more details about our Heavy Workload for 2011.

The test has 2,168,893 read operations and 1,783,447 write operations. The IO breakdown is as follows:

AnandTech Storage Bench 2011—Heavy Workload IO Breakdown
IO Size	% of Total
4KB	28%
16KB	10%
32KB	10%
64KB	4%

Only 42% of all operations are sequential, the rest range from pseudo to fully random (with most falling in the pseudo-random category). Average queue depth is 4.625 IOs, with 59% of operations taking place in an IO queue of 1.

Many of you have asked for a better way to really characterize performance. Simply looking at IOPS doesn't really say much. As a result I'm going to be presenting Storage Bench 2011 data in a slightly different way. We'll have performance represented as Average MB/s, with higher numbers being better. At the same time I'll be reporting how long the SSD was busy while running this test. These disk busy graphs will show you exactly how much time was shaved off by using a faster drive vs. a slower one during the course of this test. Finally, I will also break out performance into reads, writes and combined. The reason I do this is to help balance out the fact that this test is unusually write intensive, which can often hide the benefits of a drive with good read performance.

There's also a new light workload for 2011. This is a far more reasonable, typical every day use case benchmark. Lots of web browsing, photo editing (but with a greater focus on photo consumption), video playback as well as some application installs and gaming. This test isn't nearly as write intensive as the MOASB but it's still multiple times more write intensive than what we were running last year.

As always I don't believe that these two benchmarks alone are enough to characterize the performance of a drive, but hopefully along with the rest of our tests they will help provide a better idea.

The testbed for Storage Bench 2011 has changed as well. We're now using a Sandy Bridge platform with full 6Gbps support for these tests. All of the older tests are still run on our X58 platform.

AnandTech Storage Bench 2011—Heavy Workload

We'll start out by looking at average data rate throughout our new heavy workload test:

While we saw a pretty significant difference between 3Gbps and 6Gbps interfaces with the Intel 510 and Vertex 3, but the same can't be said about Crucial's m4. There's only a 7% performance improvement seen by using a 6Gbps connector on our Sandy Bridge system. Even more interesting is that performance actually drops a bit compared to the C300. We saw this in some of our synthetic Iometer tests and it's definitely reflected here.

The breakdown of reads vs. writes tells us more of what's going on:

The drop in sequential and random read performance we noticed seems to be at fault for the m4's lower-than-C300 performance. Looking at write speeds we actually see an improvement over the C300:

The next three charts just represent the same data, but in a different manner. Instead of looking at average data rate, we're looking at how long the disk was busy for during this entire test. Note that disk busy time excludes any and all idles, this is just how long the SSD was busy doing something:

AnandTech Storage Bench 2011—Light Workload

Our new light workload actually has more write operations than read operations. The split is as follows: 372,630 reads and 459,709 writes. The relatively close read/write ratio does better mimic a typical light workload (although even lighter workloads would be far more read centric).

The I/O breakdown is similar to the heavy workload at small IOs, however you'll notice that there are far fewer large IO transfers:

AnandTech Storage Bench 2011—Light Workload IO Breakdown
IO Size	% of Total
4KB	27%
16KB	8%
32KB	6%
64KB	5%

Despite the reduction in large IOs, over 60% of all operations are perfectly sequential. Average queue depth is a lighter 2.2029 IOs.

Our light workload actually does a lot better on the m4. The m4 is virtually tied with Intel's SSD 510 as the second fastest drive we've tested thus far over a 6Gbps interface:

Over a 3Gbps interface the m4 is actually no faster than the old C300.

Performance vs. Transfer Size

All of our Iometer sequential tests happen at a queue depth of 1, which is indicative of a light desktop workload. It isn't too far fetched to see much higher queue depths on the desktop. The performance of these SSDs also greatly varies based on the size of the transfer. For this next test we turn to ATTO and run a sequential write over a 2GB span of LBAs at a queue depth of 4 and varying the size of the transfers.

The C300 and m4 performance curves are really interesting. The old C300 had much better small file sequential performance, while the m4 jumps ahead at larger block sizes. Most sequential transfers seem to happen at 64KB in Windows 7, which actually means the old C300 should perform better in sequential reads a lot of the time.

It's hard to tell given how crowded this chart is, but the m4 does have much better sequential write characteristics than the C300 regardless of transfer size. These results agree what what we saw in Iometer.

AS-SSD Incompressible Sequential Performance

The AS-SSD sequential benchmark uses incompressible data for all of its transfers. The result is a pretty big reduction in sequential write speed on SandForce based controllers.

AS-SSD paints the m4 in a better light than our other tests. Here the m4 ties the Vertex 3 in sequential write speed thanks to AS-SSD's use of incompressible data. Read performance is also pretty impressive, although still lower than Intel's 510 and the Vertex 3.

Overall System Performance using PCMark Vantage

Next up is PCMark Vantage, another system-wide performance suite. For those of you who aren’t familiar with PCMark Vantage, it ends up being the most real-world-like hard drive test I can come up with. It runs things like application launches, file searches, web browsing, contacts searching, video playback, photo editing and other completely mundane but real-world tasks. I’ve described the benchmark in great detail before but if you’d like to read up on what it does in particular, take a look at Futuremark’s whitepaper on the benchmark; it’s not perfect, but it’s good enough to be a member of a comprehensive storage benchmark suite. Any performance impacts here would most likely be reflected in the real world.

Keep in mind that PCMark Vantage is run on our older testbed with a Marvell 6Gbps SATA controller so the numbers will be much lower than on a Sandy Bridge platform.

PCMark Vantage agrees with our Light 2011 workload—the m4 is the second fastest drive we've tested here.

SYSMark 2007

SYSMark 2007 isn't nearly as demanding on the storage subsytem so we're mostly bottlenecked elsewhere. It is a good reminder that in CPU bound applications you won't see any benefit to buying an SSD.

AnandTech Storage Bench 2010

To keep things consistent we've also included our older Storage Bench. Note that the old storage test system doesn't have a SATA 6Gbps controller, so we only have 3Gbps results for the 6Gbps drives.

The first in our benchmark suite is a light/typical usage case. The Windows 7 system is loaded with Firefox, Office 2007 and Adobe Reader among other applications. With Firefox we browse web pages like Facebook, AnandTech, Digg and other sites. Outlook is also running and we use it to check emails, create and send a message with a PDF attachment. Adobe Reader is used to view some PDFs. Excel 2007 is used to create a spreadsheet, graphs and save the document. The same goes for Word 2007. We open and step through a presentation in PowerPoint 2007 received as an email attachment before saving it to the desktop. Finally we watch a bit of a Firefly episode in Windows Media Player 11.

There’s some level of multitasking going on here but it’s not unreasonable by any means. Generally the application tasks proceed linearly, with the exception of things like web browsing which may happen in between one of the other tasks.

The recording is played back on all of our drives here today. Remember that we’re isolating disk performance, all we’re doing is playing back every single disk access that happened in that ~5 minute period of usage. The light workload is composed of 37,501 reads and 20,268 writes. Over 30% of the IOs are 4KB, 11% are 16KB, 22% are 32KB and approximately 13% are 64KB in size. Less than 30% of the operations are absolutely sequential in nature. Average queue depth is 6.09 IOs.

The performance results are reported in average I/O Operations per Second (IOPS):

Lighter read-heavy workloads do very well on the m4. Thankfully for Crucial, most user workloads tend to be very read intensive. Over a 3Gbps interface, the m4 is a bit faster than Intel's 320 in our typical workload from 2010.

If there’s a light usage case there’s bound to be a heavy one. In this test we have Microsoft Security Essentials running in the background with real time virus scanning enabled. We also perform a quick scan in the middle of the test. Firefox, Outlook, Excel, Word and Powerpoint are all used the same as they were in the light test. We add Photoshop CS4 to the mix, opening a bunch of 12MP images, editing them, then saving them as highly compressed JPGs for web publishing. Windows 7’s picture viewer is used to view a bunch of pictures on the hard drive. We use 7-zip to create and extract .7z archives. Downloading is also prominently featured in our heavy test; we download large files from the Internet during portions of the benchmark, as well as use uTorrent to grab a couple of torrents. Some of the applications in use are installed during the benchmark, Windows updates are also installed. Towards the end of the test we launch World of Warcraft, play for a few minutes, then delete the folder. This test also takes into account all of the disk accesses that happen while the OS is booting.

The benchmark is 22 minutes long and it consists of 128,895 read operations and 72,411 write operations. Roughly 44% of all IOs were sequential. Approximately 30% of all accesses were 4KB in size, 12% were 16KB in size, 14% were 32KB and 20% were 64KB. Average queue depth was 3.59.

Last year's heavy multitasking workload was also predominantly read heavy. The m4 does very well here again, roughly equaling the performance of OCZ's Vertex 3.

The gaming workload is made up of 75,206 read operations and only 4,592 write operations. Only 20% of the accesses are 4KB in size, nearly 40% are 64KB and 20% are 32KB. A whopping 69% of the IOs are sequential, meaning this is predominantly a sequential read benchmark. The average queue depth is 7.76 IOs.

Gaming performance is good but we're of course bottlenecked by the 3Gbps SATA interface in this test.

Power Consumption

The m4 has pretty good idle and sequential power characteristics. It's only under high queue depth random writes that the m4 looks a little power hungry, and that's only because the transfer rates we're talking about are so very high.

Final Words

I'm not sure whether to call the m4 an evolutionary upgrade in performance or a shift in performance. Write speed is faster across the board, but read speed took a definite hit compared to the C300. Overall Crucial has a faster drive on its hands, one that's particularly well suited to most of our lighter workloads. It's only in our new 2011 heavy multitasking workload that the m4 really fell short. For your average desktop usage model, the m4 is either the best or second best you can get.

I am a bit put off by the fact that the m4 doesn't seem to have the peak sequential performance of some of the other next-generation drives we've reviewed. The Vertex 3 and Intel SSD 510 both do much better in sequential transfer speeds than the m4. To Crucial's credit however, without any data deduplication/compression it delivers the best 4KB random write performance we've seen to date.

My remaining concerns with the m4 are really not that different from those I had with the C300. Crucial's very late garbage collection allows the possibility for some very poor write speeds over time. If you're running in a configuration without TRIM support, I'd say this is enough to rule out the m4. Sure performance should recover with sequential write passes, however if your workload isn't sufficiently sequential then this could pose a problem. If you do have a TRIM enabled OS I'm not entirely sure how the m4 will behave over time. TRIM should keep things running smoothly but that will largely depend on workload. Again, I think that for most desktop/notebook users the m4 will do just fine but it's tough to say for sure without months of testing under my belt. In other words, like any other brand new SSD—approach with caution.

We should have the final Vertex 3 in house soon, but it's looking like all cards are on the table for this round. If SandForce/OCZ can manage to deliver a well tested, reliable product it may be difficult to recommend an alternative.