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

  • alpha754293 - Friday, June 24, 2011 - link

    Can you run h2benchw on the drives and post the results? Thanks.
  • doylecc - Friday, June 24, 2011 - link


    What write amplification did you get during your use of the SSD 510?

    Thanks, and good review.
  • bse8128 - Friday, June 24, 2011 - link

    I was wondering for a moment how (128GB-120GB)/128GB can be 13%, but then I noticed that it's really 120GB but 128 GiB. It's a bit confusing to call both 10^9 and 2^30 just "GB".
  • jwilliams4200 - Friday, June 24, 2011 - link

    Yes, I really wish Anand would keep his GB and GiB units straight. It makes his articles very difficult to follow sometimes.
  • Marian666 - Saturday, June 25, 2011 - link

    Who the hell asks for qd32?? Like there werent enough of such tests on internet, and anand was like the only one giving us qd3 4k read test....

    And whats with "depth of 32 instead of 3" ?? How hard it is to test drives in both queue depths


  • MamiyaOtaru - Saturday, June 25, 2011 - link

    this site used to be like my bible for SSDs. This continued pushing of OCZ in spite of manifest and multiple failures in their drives has soured me on the whole thing a bit.

    That aside, I went with Intel for a Macbook (with Snow Leopard) that had seen a couple hard drives die. It doesn't seem faster at all. I'm not willing to trade reliability for a few more percentage points, so some other drive is not an option. And if an SSD can't improve on the performance offered by a laptop drive I can't imagine what motivation I'd have to put one in my desktop.
  • somedude1234 - Saturday, June 25, 2011 - link

    I had the exact opposite experience. I replaced a 7.2K laptop HDD with an Intel 80GB G2 SSD in my Dell D810 (running XP at the time) and have since migrated that same SSD to a Dell E6400 running Win7. The difference in overall system performance after moving to the SSD was absolutely clear in both XP and Win7, across both laptops.

    Granted, you're working in a Mac environment, but I will never again willingly deal with a workstation that isn't running an SSD for the OS drive.

    I'm currently running my G2 with less than 5GB free, so it feels a bit slower than it did when there was > 20 GB free, but it's still night and day vs any HDD.

    The system is used every day for productivity apps (primarily outlook/word/excel) as well as SAP client, putty, remote desktop, etc.
  • Movieman420 - Saturday, June 25, 2011 - link

    Over the last few days, there has been a spark that has brought on a 'meeting of the minds' in this thread:


    Be warned, this is a deeply technical discussion...I only thought I was up to speed on SSDs...lol
  • cactusdog - Sunday, June 26, 2011 - link

    That is just another theory in a long line of theories. It doesnt explain why people have issues on other boards without IME.

    OCZ have tried to blame everything from sata cables to install methods.

    If its only 1% with issues i dont know why OCZ are putting so much effort into it. It would be better for them to just give those 1% a refund to move to another drive.

    As it stands, the OCZ forum and staff is preoccupied with this issue that "only affects 1%". It looks much worse than that and no doubt some people will be put off by all the discussion about BSOD's

    If it is only 1% with issues, OCZ are handling the situation badly.

  • mcg75 - Sunday, June 26, 2011 - link

    I was getting the bsod so I was watching their forums waiting for the result. OCZ said system was setup wrong. Then there are issues with secure erase in parted magic not working properly. So I went through the hassle of doing it all over again according to Tony's guide with no rst loaded. Still got bsod. Now IME is corrupting cmos. Told Tony that IME wasn't loaded when I got bsod. He only replied that I didn't follow his guide by not installing IME. Later in the thread in response to a post, Tony said we could run without IME using MS ahci which is exactly what I was doing.

    I've been setting up win7 the exact same way for years. First on a X-25m and no issues. Next a C300 with no issues. Now I setup the same way on a V3 and get bsod and it's all my fault. All OCZ has to do is look around at other forums and see there are far more than 1% being effected by this and it's cross platform with the Sandforce controller being the only constant.

    They said they were able to recreate the same problem on other competitors ssd beside V3. When asked, Tony pointed to stuttering experienced by c300 users that was taken care of by firmware. That was his only example, no others and no c300 bsod either.

    Now with firmware that reduces performance to get rid of bsod, we're back to the same old story that none of OCZ computers are showing the slowdown just like none of their computers would do the bsod. I dropped 50 points in as-ssd after new firmware was put in then secure erase and fresh install Win7. Obviously, I must be doing something wrong again.

    Never again OCZ, never again.

Log in

Don't have an account? Sign up now