Original Link: http://www.anandtech.com/show/4341/ocz-vertex-3-max-iops-patriot-wildfire-ssds-reviewed



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

OCZ isn't the only company experimenting with SF-2281 drives and 32nm NAND. Patriot sent me the Wildfire, its first SF-2281 SSD. After a quick run through some performance tests I grew suspicious as it performed a lot like the Vertex 3 MAX IOPS I just tested. Cracking open the case I found the reason:

The Wildfire also uses 32nm Toshiba NAND. The 120GB drive Patriot sent has a 16 chip, 2 die per package configuration - compared to 8 chips with 4 die per package in the Vertex 3 MI. I don't see an advantage for one approach vs. the other. Patriot is targeting a $299 MSRP for the Wildfire, which would put it lower than the Vertex 3 MAX IOPS - although anything is possible once the drive goes on sale on the 28th of this month.

Patriot confirmed that the Wildfire would only use 32nm Toshiba NAND and that any NAND vendor changes would take place in other lines or subsets of the Wildfire brand.

Patriot uses a different PCB layout from OCZ. I don't know that there's an advantage to either layout, they are just different.

The unit I have here shipped with SF firmware revision 3.19, which is equivalent to OCZ's revision 2.08 firmware as far as I know. No word on when we'll see a 2.09 equivalent.

Performance of the Wildfire (as you'll see from the tests that follow) is identical to the Vertex 3 MAX IOPS. To keep the charts more manageable I've only included 6Gbps results from the Wildfire in most areas. Performance on a 3Gbps interface is identical to a 3Gbps Vertex 3 MAX IOPS as you'd expect.

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


A Note on Real World Performance

The majority of our SSD test suite is focused on I/O bound tests. These are benchmarks that intentionally shift the bottleneck to the SSD and away from the CPU/GPU/memory subsystem in order to give us the best idea of which drives are the fastest. Unfortunately, as many of you correctly point out, these numbers don't always give you a good idea of how tangible the performance improvement is in the real world.

Some of them do. Our 128KB sequential read/write tests as well as the ATTO and AS-SSD results give you a good indication of large file copy performance. Our small file random read/write tests tell a portion of the story for things like web browser cache accesses, but those are difficult to directly relate to experiences in the real world.

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. Take application launch time for example. I stopped including that data in our reviews because the graphs ended up looking like this:

All of the SSDs performed the same. It's not just application launch times though. Here is data from our Chrome Build test timing how long it takes to compile the Chromium project:

Build Chrome

Even going back two generations of SSDs, at the same capacity nearly all of these drives perform within a couple of percent of one another. Note that the Vertex 3 is even a 6Gbps drive and doesn't even outperform its predecessor.

So do all SSDs perform the same then? The answer there is a little more complicated. As I mentioned at the start of this review, I do long term evaluation of all drives I recommend in my own personal system. If a drive is particularly well recommended I'll actually hand out drives for use in the systems of other AnandTech editors. For example, back when I wanted to measure actual write amplification on SandForce drives I sent three Vertex 2s to three different AnandTech editors. I had them use the drives normally for two - three months and then looked at the resulting wear on the NAND.

In doing these real world use tests I get a good feel for when a drive is actually faster or slower than another. My experiences typically track with the benchmark results but it's always important to feel it first hand. What I've noticed is that although single tasks perform very similarly on all SSDs, it's during periods of heavy I/O activity that you can feel the difference between drives. Unfortunately these periods of heavy I/O activity aren't easily measured, at least in a repeatable fashion. Getting file copies, compiles, web browsing, application launches, IM log updates and searches to all start at the same time while properly measuring overall performance is near impossible without some sort of automated tool. Unfortunately most system-wide benchmarks are more geared towards CPU or GPU performance and as a result try to minimize the impact of I/O.

The best we can offer is our Storage Bench suite. In those tests we are actually playing back the I/O requests captured of me using a PC over a long period of time. While all other bottlenecks are excluded from the performance measurement, the source of the workload is real world in nature.

What you have to keep in mind is that a performance advantage in our Storage Bench suite isn't going to translate linearly into the same overall performance impact on your system. Remember these are I/O bound tests, so a 20% increase in your Heavy 2011 score is going to mean that the drive you're looking at will be 20% faster in that particular type of heavy I/O bound workload. Most desktop PCs aren't under that sort of load constantly, so that 20% advantage may only be seen 20% of the time. The rest of the time your drive may be no quicker than a model from last year.

The point of our benchmarks isn't to tell you that only the newest SSDs are fast, but rather to show you the best performing drive at a given price point. The best values in SSDs are going to be last year's models without a doubt. I'd say that the 6Gbps drives are interesting mostly for the folks that do a lot of large file copies, but for most general use you're fine with an older drive. Almost any SSD is better than a hard drive (almost) and as long as you choose a good one you won't regret the jump.

I like the SF-2281 series because, despite things like the BSOD issues, SandForce has put a lot more development and validation time into this controller than its predecessor. Even Intel's SSD 320 is supposed to be more reliable than the X25-M G2 that came before it. Improvements do happen from one generation to the next but they're evolutionary - they just aren't going to be as dramatic as the jump from a hard drive to an SSD.

So use these numbers for what they tell you (which drive is the fastest) but keep in mind that a 20% advantage in an I/O bound scenario isn't going to mean that your system is 20% faster in all cases.



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.

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.

Desktop Iometer - 4KB Random Write (4K Aligned) - 8GB LBA Space

The numbers here are what you'll see echoed throughout the entire review. The 120GB Wildfire and Vertex 3 MAX IOPS perform like a 240GB Vertex 3. The Patriot and OCZ drives perform identically as they are similarly equipped.

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:

Desktop Iometer - 4KB Random Write (8GB LBA Space QD=32)

Desktop Iometer - 4KB Random Read (4K Aligned)

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. These results are going to be the best indicator of large file copy performance.

Desktop Iometer - 128KB Sequential Read (4K Aligned)

Desktop Iometer - 128KB Sequential Write (4K Aligned)



AnandTech Storage Bench 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.

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.

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:

Heavy Workload 2011 - Average Data Rate

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

Heavy Workload 2011 - Average Read Speed

Heavy Workload 2011 - Average Write Speed

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:

Heavy Workload 2011 - Disk Busy Time

Heavy Workload 2011 - Disk Busy Time (Reads)

Heavy Workload 2011 - Disk Busy Time (Writes)



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.

Light Workload 2011 - Average Data Rate

Light Workload 2011 - Average Read Speed

Light Workload 2011 - Average Write Speed

Light Workload 2011 - Disk Busy Time

Light Workload 2011 - Disk Busy Time (Reads)

Light Workload 2011 - Disk Busy Time (Writes)



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.

Incompressible Sequential Read Performance - AS-SSD

Incompressible Sequential Write Performance - AS-SSD



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.

PCMark Vantage - Overall Suite

PCMark Vantage - Memories Suite

PCMark Vantage - TV & Movies Suite

PCMark Vantage - Gaming Suite

PCMark Vantage - Music Suite

PCMark Vantage - Communications Suite

PCMark Vantage - Productivity Suite

PCMark Vantage - HDD Suite



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 one result 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):

Light Workload 2010 - Average IOPS

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.

Heavy Workload 2010 - Average IOPS

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 Workload 2010 - Average IOPS



TRIM Performance

In practice, SandForce based drives running a desktop workload do very well and typically boast an average write amplification below 1 (more writes to the device than actual writes to NAND). My personal SF-1200 drive had a write amplification of around 0.6 after several months of use. However if subjected to a workload composed entirely of incompressible writes (e.g. tons of compressed images, videos and music) you can back the controller into a corner.

To simulate this I filled the drive with incompressible data, ran a 4KB (100% LBA space, QD32) random write test with incompressible data for an hour, and then ran AS-SSD (another incompressible data test) to see how low performance could get:

OCZ Vertex 3 240GB MAX IOPS - Resiliency - AS SSD Sequential Write Speed - 6Gbps
  Clean After 1hr Torture After TRIM
OCZ Vertex 3 MI 240GB 247.9 MB/s 50.1 MB/s 160.6 MB/s

I usually run this test for only 20 minutes but after seeing an unusually resilient performance by the 240GB drives I decided to extend the test period to a full 60 minutes. Performance does drop pretty far at that point, down to a meager 50MB/s. TRIMing the drive does restore some performance but not all. If you have a workload that uses a lot of incompressible data (e.g. JPGs, H.264 videos, highly random datasets etc...) then SandForce just isn't for you.

Power Consumption

The MAX IOPS drive does use significantly more power than the regular Vertex 3, particularly under heavy load with incompressible data. There are more NAND die firing in parallel which results in higher power consumption. For a notebook that's going to be on battery power most of the time, you may want to consider a standard SF-2281 with 25nm IMFT NAND.

Drive Power Consumption - Idle

Drive Power Consumption - Sequential Write

Drive Power Consumption - Random Write



Final Words

This new batch of 32nm Toshiba based SF-2281 drives fixes my issue with the 120GB Vertex 3. These drives 120GB are now competitive with both Intel's SSD 510 and the 240GB Vertex 3. For desktop users looking for the best absolute performance at the 120GB price point, these are the SF-2281 drives you've been looking for. How much more are they worth than the regular 25nm IMFT versions however? Currently on Newegg you can get a 25nm 120GB Vertex 3 for $254.99 vs. $309.99 for the MAX IOPS drive. Personally I'd rather save the $55 and put it towards a future, higher capacity drive in another year or so than take the performance benefit. In the real world you'd be hard pressed to tell the difference between these two, it's only in very specific, demanding IO situations where the MAX IOPS/Wildfire drives will show a tangible benefit.

Between OCZ and Patriot the performance is virtually identical. Kudos for Patriot on not only being aggressive on MSRP out of the gate, but also picking the best possible NAND configuration for performance on day one. The Wildfire is Patriot's MAX IOPS equivalent, an excellent first entry into the SF-2281 market.

It remains to be seen how aggressively Patriot pursues firmware updates on the Wildfire. Historically no company has really been as aggressive there as OCZ so it'll be interesting to see how Patriot handles the BSOD issue going forward. According to Patriot the latest 3.19 firmware it's shipping on the drives resolved the limited number of BSOD issues it saw in its testing, however it's my understanding that this is not the same firmware that OCZ just pushed out (v2.09) so the BSOD issue could still be present.

I must reiterate that I do believe the SandForce BSOD issue is fairly limited. I run a Vertex 3 in my own system and have yet to see these BSOD issues first hand. However I definitely share the hesitation to jump on board here until the root cause is completely understood and problems definitely solved. If we look outside of the SandForce world, I still believe the Intel SSD 510 is a great balance of performance and reliability. If you want something with an even lower failure rate, there's always the Intel SSD 320 although you do give up performance and 6Gbps support to get that. Note that all of these drives (excluding if you do have a platform that exhibits BSOD issues with SF-2281 drives) should be more reliable than a hard drive so it really boils down to which makes you feel most comfortable.

Log in

Don't have an account? Sign up now