Let's start with the elephant in the room. There's a percentage of OCZ Vertex 3/Agility 3 customers that have a recurring stuttering/instability issue. The problem primarily manifests itself as regular BSODs under Windows 7 although OCZ tells me that the issue is cross platform and has been seen on a MacBook Pro running OS X as well.

How many customers are affected? OCZ claims it's less than two thirds of a percent of all Vertex 3/Agility 3 drives sold. OCZ came up with this figure by looking at the total number of tech support enquiries as well as forum posts about the problem and dividing that number by the total number of drives sold through to customers. I tend to believe OCZ's data here given that I've tested eight SF-2281 drives and haven't been able to duplicate the issue on a single drive/configuration thus far.

Most of the drives were from OCZ and I've tested them all on four separate platforms - three Windows 7 and one OS X. The latter is my personal system where I have since deployed a 240GB Vertex 3 in place of Intel's SSD 510 for long term evaluation. If you're curious, the 3 months I had the 510 in the MacBook Pro were mostly problem-free. It's always tough narrowing down the cause of system-wide crashes so it's hard to say whether or not the 510 was responsible for any of the hard-resets I had to do on the MacBook Pro while it was deployed. For the most part the 510 worked well in my system although I do know that there have been reports of issues from other MBP owners.

But I digress, there's a BSOD issue with SF-2281 drives and I haven't been able to duplicate it. OCZ has apparently had a very difficult time tracking down the issue as well. OCZ does a lot of its diagnostic work using a SATA bus analyzer, a device that lets you inspect what's actually going over the SATA bus itself rather than relying on cryptic messages that your OS gives you about errors. Apparently sticking a SATA bus analyzer in the chain between the host controller and SSD alone was enough to make the BSOD problem go away, which made diagnosing the source of the BSOD issue a pain.

OCZ eventually noticed odd behavior involving a particular SATA command. Slowing down timings associated with that command seems to have resolved the problem although it's tough to be completely sure as the issue is apparently very hard to track down.

OCZ's testing also revealed that the problem seems to follow the platform, not the drive itself. If you have a problem, it doesn't matter how many Vertex 3s you go through - you'll likely always have the problem. Note that this doesn't mean your motherboard/SATA controller is at fault, it just means that the interaction between your particular platform and the SF-2281 controller/firmware setup causes this issue. It's likely that either the platform or SSD is operating slightly out of spec or both are operating at opposite ends of the spec, but still technically within it. There's obviously chip to chip variance on both sides and with the right combination you could end up with some unexpected behaviors.

OCZ and SandForce put out a stopgap fix for the problem. For OCZ drives this is firmware revision 2.09 (other vendors haven't released the fix yet as far as I can tell). The firmware update simply slows down the timing of the SATA command OCZ and SF believe to be the cause of these BSOD issues.

In practice the update seems to work. Browsing through OCZ's technical support forums I don't see any indications of users who had the BSOD issue seeing it continue post-update. It is worth mentioning however that the problem isn't definitely solved since the true cause is still unknown, it just seems to be addressed given what we know today.

Obviously slowing down the rate of a particular command can impact performance. In practice the impact seems to be minimal, although a small portion of users are reporting huge drops in performance post-update. OCZ mentions that you shouldn't update your drive unless you're impacted by this problem, advice I definitely agree with.

What does this mean? Well, most users are still unaffected by the problem if OCZ's statistics are to be believed. I also don't have reason to believe this is exclusive to OCZ's SF-2281 designs so all SandForce drives could be affected once they start shipping (note that this issue is separate from the Corsair SF-2281 recall that happened earlier this month). If you want the best balance of performance and predictable operation, Intel's SSD 510 is still the right choice from my perspective. If you want the absolute fastest and are willing to deal with the small chance that you could also fall victim to this issue, the SF-2281 drives continue to be very attractive. I've deployed a Vertex 3 in my personal system for long term testing to see what living with one of these drives is like and so far the experience has been good.

With that out of the way, let's get to the next wave of SF-2281 based SSDs: the OCZ Vertex 3 MAX IOPS and the Patriot Wildfire.

The Vertex 3 MAX IOPS Drive

In our first review of the final, shipping Vertex 3, OCZ committed to full disclosure in detailing the NAND configuration of its SSDs to avoid any confusion in the marketplace. Existing Vertex 3 drives use Intel 25nm MLC NAND, as seen below:

A 240GB Vertex 3 using 25nm Intel NAND


Not wanting to be completely married to Intel NAND production, OCZ wanted to introduce a version of the Vertex 3 that used 32nm Toshiba Toggle NAND - similar to what was used in the beta Vertex 3 Pro we previewed a few months ago. Rather than call the new drive a Vertex 3 with a slightly different model number, OCZ opted for a more pronounced suffix: MAX IOPS.

Like the regular Vertex 3, the Vertex 3 MAX IOPS drive is available in 120GB and 240GB configurations. These drives have 128GB and 256GB of NAND, respectively, with just under 13% of the NAND set aside for use as a combination of redundant and spare area.

OCZ Vertex 3 MI 120GB

The largest NAND die you could ship at 32/34nm was 4GB - the move to 25nm brought us 8GB die. What this means is that for a given capacity, the MAX IOPS edition will have twice as many MLC NAND die under the hood. The table below explains it all:

OCZ SF-2281 NAND Configuration
  Number of NAND Channels Number of NAND Packages Number of NAND die per Package Total Number of NAND die Number of NAND per Channel
OCZ Vertex 3 120GB 8 16 1 16 2
OCZ Vertex 3 240GB 8 16 2 32 4
OCZ Vertex 3 MI 120GB 8 8 4 32 4
OCZ Vertex 3 MI 240GB 8 16 4 64 8

The standard 240GB Vertex 3 has 32 die spread across 16 chips. The MAX IOPS version doubles that to 64 die in 16 chips. The 120GB Vertex 3 only has 16 die across 16 chips while the MAX IOPS version has 32 die, but only using 8 chips. The SF-2281 is an 8-channel controller so with 32 die you get a 4-way interleave and 8-way with the 64 die version. There are obviously diminishing returns to how well you can interleave requests to hide command latencies - 4 die per channel seems to be the ideal target for the SF-2281.

OCZ Vertex 3 MI 240GB

Patriot's Wildfire
Comments Locked


View All Comments

  • Chloiber - Thursday, June 23, 2011 - link

    Hi Anand,

    is it possible to do the same (1 hour) torture tests for other SSDs such as Intel 320, Intel 510 and C300/m4? It would be interesting to see how the, in my opinion, huge performance hit with the Sandforce drives compares to other SSDs/controllers.
  • Impulses - Thursday, June 23, 2011 - link

    I think he's done similar tests in past reviews, though probably not the very same 60 min test. Crucial drives had issues recovering from similar situations, and Intel drives were the most resilient (shocking right?). The SF drives are particularly susceptible to that sort of degradation when hammering them with incompressible data due to the very nature of how their compression algorithm works.

    That's one reason I've never been very high on SF drives... Currently I have two Intel drives being used as OS drives (where that sorta scenario is improbable), but if I decided to upgrade the desktop OS drive I could very well end up using one of those smaller drives as a scratch disk for working with video, or as a spare disk for game installs. SF wouldn't necessarily be ideally suited for that.
  • Chloiber - Friday, June 24, 2011 - link

    Yes, but without the same 60mins the comparison is pretty much useless, sadly. You can see this very well in the Agility 3 review - nearly no performance drop with 20min torture test.
    I know that the SF drives drop performance to about 65% (write), both SF1 and SF2. And that it's not a state that you reach when you torture your drive is known because nearly everyone who does a ASS benchmark some month after the initial use show the lower performance (in case of SF2 that's 70-90MB/s seq. write).
    But I'd like to see a direct comparison from Anand, would just be great.

    And yes - that's also a reason why I won't buy SF drives. I just don't like it how they try to confuse customers. They say 450MB/s+ write...yeah right. In a very special case. And even worse, it drops down even more. Intel is honest about the performance of their SSD, that's what I like about it. But I'm pretty sure SF gained countless customers just because of those "incredible" performance stats.
  • Phil NBR - Thursday, June 23, 2011 - link

    "So why not exclusively use real world performance tests? It turns out that although the move from a hard drive to a decent SSD is tremendous, finding differences between individual SSDs is harder to quantify in a single real world metric. "

    I don't think it's that hard. Sites like Hardwareheaven and Techspot show meaningful differences between SSDs in real world settings. I would like to see Anandtech include real real world benchmarks again. I/O bound benchmarks don't tell the whole story.
  • ckryan - Thursday, June 23, 2011 - link

    It's my belief that these real world tests are contrived in and of themselves to some degree.
  • Impulses - Thursday, June 23, 2011 - link

    I don't frequent Hardware Heaven often but I do like the way they compare and present results for their GPU reviews, so I went looking for their "real world" SSD tests when I saw that comment. Out of the 5 or 6 tests like 3 or 4 are just large sequential read/write tests... Sure seeing 200 minutes vs 210 minutes might be somewhat more intuitive than a generic benchmark score, but it doesn't tell you a whole lot more tbh. It's all basically just OS/game install tests and file transfer/scan tests, with two exceptions...

    One is their OS boot up test, where the difference between all current drives is usually 2-3 sec at most (time to hibernate and resume might be more valuable imo), and the other is an HD video capture test that might actually be the only real world test they're doing of any actual value. It showcases the biggest disparity between the drives (due to sequential write speeds using raw uncompressed footage), and it really is something you could be doing day in and day out and not easily represented by synthetic benchmarks or some of the other test scenarios Anand uses. Worth looking into...
  • cjs150 - Thursday, June 23, 2011 - link

    Seems to be a lot of conspiracy theorists about today.

    I read Anandtech because I do not detect bias. When it is wrong he will tell us. Sometimes I do not understand what he is saying - but that is because I am an amateur geek not a full time pro!

    Now my noob question.

    What is best way of setting up a system with an SSD and a traditional HD. Should I use the SSD for OS and programs and the HD for widows swap file. Or would it be fine to use the SSD for all OS functions? Happy to partition the HD so that there is a small partition for the OS swap
  • Impulses - Thursday, June 23, 2011 - link

    Leave the swap file alone, Windows manages it just fine and a Windows engineer was quoted during the launch of Win7 as saying that SSD are particularly well suited for the swap file's purpose... If you have enough RAM it's gonna see little use besides background maintenance Windows does of active processes. Just install your OS and apps as you normally do on the SSD, let Win7 partition it (or Vista, if you're using XP you'll wanna look into proper partition alignment), and then use your HDD for large game installs that don't fit on the SSD and data.

    If you have lots of games at any one time it's worth looking into system links or junction links, they provide any easy way to move game directories to the SSD and back w/o altering or affecting the existing install (or w/o messing w/registry keys, it's like an OS level shortcut that's transparent to the programs).

    If you have a small SSD (and particularly if you have lots of RAM), it's worth turning off hibernate as the hibernate file will take up a few GB of space on the drive (depending on the amount of RAM). Swap file should be dynamic and shouldn't grow too large if it's rarely used.
  • jwilliams4200 - Thursday, June 23, 2011 - link

    Did I miss where you commented on the Desktop Iometer - 4KB Random Read chart?

    The 120GB Vertex 3 Max IOPS and the Patriot Wildfire were in the basement, with 35 MB/s or lower performance.

    What is going on?
  • Anand Lal Shimpi - Thursday, June 23, 2011 - link

    The 240GB Vertex 3 results were a typo, I've updated/corrected that entry. The Toshiba 32nm drives are even slower, likely due to the specific characteristics of that NAND vs. the IMFT devices.

    Random read performance is a weak area of many drives this generation for some reason. Even Crucial's m4 is slower than last year's C300 in this department.

    Take care,

Log in

Don't have an account? Sign up now