OCZ Agility 3 (240GB) Review
by Anand Lal Shimpi on May 24, 2011 2:53 AM ESTOCZ has been at the forefront of each generation of SandForce SSD release since the debut of the SF-1500 based Vertex Limited Edition. More recently the Vertex 3 was the first client SSD to use SandForce's SF-2281 controller. Many of you have written me asking if the Vertex 3 is worth the additional cost over the Vertex 2. Given that you can pick up a 120GB Vertex 2 for $210 ($180 after rebate), and a 120GB Vertex 3 will set you back $300 flat it's tough to recommend the latter despite the performance improvements. If you don't have a 6Gbps platform (e.g. Intel 6-series, AMD 8-series) the Vertex 2 vs. Vertex 3 decision is a little easier to make, otherwise the newer, faster Vertex 3 is quite tempting.
There's another issue holding users back from the Vertex 3: capacity. The Vertex 3 is available in 120, 240 and 480GB versions, there is no 60GB model. If you're on a budget or like to plan frequent but rational upgrades, the Vertex 3 can be a tough sell.
Enter the Agility 3, OCZ's mainstream SF-2281 drive.
Architecturally the Agility 3 is identical to the Vertex 3. You get the same controller running similar firmware, and as a result post similar peak performance stats (note the use of the word peak):
OCZ SF-2200 Lineup | ||||||||
Specs (6Gbps) | Agility 3 | Agility 3 120GB | Vertex 3 120GB | Agility 3 240GB | Vertex 3 240GB | Vertex 3 480GB | ||
Raw NAND Capacity | 64GB | 128GB | 128GB | 256GB | 256GB | 512GB | ||
Spare Area | ~6.3% | ~12.7% | ~12.7% | ~12.7% | ~12.7% | ~12.7% | ||
User Capacity | 55.8GB | 111.8GB | 111.8GB | 223.5GB | 223.5GB | 447.0GB | ||
RAISE | No | Yes | Yes | Yes | Yes | Yes | ||
Number of NAND Devices | 8 | 16 | 16 | 16 | 16 | 16 | ||
Number of die per Device | 1 | 1 | 1 | 2 | 2 | 4 | ||
NAND Type | ONFI 1.0 | ONFI 1.0 | ONFI 2.0 | ONFI 1.0 | ONFI 2.0 | ONFI 2.0 | ||
Max Read | Up to 525 MB/s | Up to 525 MB/s | Up to 550MB/s | Up to 525 MB/s | Up to 550MB/s | Up to 530MB/s | ||
Max Write | Up to 475 MB/s | Up to 500 MB/s | Up to 500MB/s | Up to 500 MB/s | Up to 520MB/s | Up to 450MB/s | ||
4KB Random Read | 10K IOPS | 20K IOPS | 20K IOPS | 35K IOPS | 40K IOPS | 50K IOPS | ||
4KB Random Write | 50K IOPS | 50K IOPS | 60K IOPS | 45K IOPS | 60K IOPS | 40K IOPS | ||
MSRP | $134.99 | $229.99 | $249.99 | $419.99 | $499.99 | $1799.99 | ||
Street Price | ? | ? | $299.99 | ? | $559.99 | $1799.99 |
OCZ has started publishing both peak and incompressible write performance data, but only on its product sheets. While peak performance isn't affected, incompressible performance is. Using AS-SSD as a benchmark, OCZ claims the Agility 3 is only able to muster about 200MB/s for peak sequential reads/writes on the 240GB drive - that's less than half the score the Vertex 3 gets in AS-SSD's read test. Our benchmarks, as you'll soon see, confirm the deficit.
If it's not the controller causing this, and it's not the firmware - then it's the NAND. The Agility 3 (and Solid 3) both use asynchronous NAND. What does that mean? Let's find out.
Asynchronous NAND: An ONFi History Lesson
It takes 50µs to read 8KB from a 25nm Intel NAND die. That works out to a staggering 156MB/s, from a single NAND die. Even the old 50nm stuff Intel used in the first X25-M could pull 4KB in 50µs or ~78MB/s. The original X25-M had 10 channels of NAND, giving it the ability to push nearly 800MB/s of data. Of course we never saw such speeds, as it's only one thing to read a few KB of data from a NAND array and dump it into a register. It's another thing entirely to transfer that data over an interface to the host controller.
ONFi 1.0 limited NAND performance considerably
Back in 2006 the Open NAND Flash Interface (ONFi) workgroup was formed with the task of defining a standardized interface for NAND Flash. Today, Intel and Micron are the chief supporters of ONFi while Toshiba and Samsung abide by a separate, comparable standard.
As is typically the case, the first standard out of the workgroup featured very limited performance. ONFi 1.0 topped out at 50MB/s, which was clearly the limiting factor in NAND transfer speed (see my example above). The original ONFi spec called for an asynchronous interface, as in one not driven by a clock signal. Most logic these days is synchronous, meaning it operates off of a host clock frequency. Depending on the architecture, all logic within a synchronously clocked system will execute/switch whenever the clock signal goes high, low or both. Asynchronous logic on the other hand looks for a separate signal, similar to a clock, but not widely distributed - more like a simple enable pin. In the asynchronous NAND world this is the role of the RE, WE and CLE (read/write/command-latch enable) signals.
ONFi 2.0 brought the move to source synchronous clocking, as well as double data rate (DDR) operation. Not only were ONFi 2.0 NAND devices tied to a clock frequency, transfers happened on both rising and falling edges of the clock - a similar transition was made in SDRAM over a decade ago. While ONFi 1.0 NAND was good for up to 50MB/s, ONFi 2.0 increased the interface speed to 133MB/s. Present day synchronous ONFi 2.1/2.2 NAND is no longer interface limited as the spec supports 166MB/s and 200MB/s operating modes. Work on ONFi 3.0 is being done now to take the interface up to 400MB/s.
The Agility 3
OCZ sent us a 240GB Agility 3 for review. Inside it looks like this:
You see the SF-2281 controller in its usual spot and to the right of it are eight 25nm Micron NAND devices. Flip the board over and you get another eight.
As always, we look at the part number to tell us what's going on. Micron's part numbers are a little different than Intel's but the key things to pay attention to here are the 128G (128Gbit packages, 16GB per package) and characters 11 and 14. Character 11 here is an F, which corresponds to 2 die per package (2 x 8GB 25nm die in each NAND device) while number 14 is an A, indicating that this is asynchronous NAND. To date I've only encountered 25nm synchronous (represented by the letter B) NAND, but as with any other silicon device there's always a cost savings if you can sacrifice performance.
Equipped with asynchronous NAND, the Agility 3's max performance is limited to 50MB/s per channel compared to 200MB/s per channel in the Vertex 3. The Vertex 3 doesn't come close to saturating its per-channel bandwidth so there's a chance that this change won't make much of a difference. To further tilt things in the Agility 3's favor, remember SandForce's controller throws away around 40% of all of your data thanks to its real time compression/deduplication algorithms - further reducing the NAND bandwidth requirements. When a Vertex 3 pushes 500MB/s that's not actual speed to NAND, it's just how fast the SF controller is completing its tasks. In a typical desktop user workload without too much in the way of incompressible data access, the Agility 3 should perform a lot like a Vertex 3.
Cost Savings and a 60GB Drive
I mentioned the only benefit to asynchronous NAND being a cost savings, if we go by OCZ's MSRPs the savings don't look too great at 120GB: here the Agility 3 is $229.99 vs. $249.99 according to OCZ. Street pricing tells a different (more expensive) story for the Vertex 3. The 120GB drive is more like $299.99, which would mean the Agility 3 (if its MSRP is accurate) would be a full $70 cheaper. Move to 240GB and the gap likely widens.
With the Agility 3, OCZ is also introducing a 60GB model. SandForce's NAND redundancy technology called RAISE, requires an entire NAND die be sacrificed and added to the spare area pool in the event of a NAND failure. At 25nm a single die is 8GB, which would mean a 64GB drive would lose 1/8 of its capacity just due to RAISE. Get rid of another 6.3% of the drive for the standard spare area and you're looking at a pretty high cost per usable gigabyte.
One feature of the SF-2200 firmware however is the ability to disable RAISE. I've never advocated it simply because I like the idea of being able to recover from a failed NAND die in the array, but at the 60GB capacity OCZ felt it was better left turned off (otherwise the drive would have to be sold as a 56GB drive instead).
Entire NAND die failures are pretty rare but it's still possible that one could happen. The 60GB Agility 3, as a result, makes a potential reliability tradeoff for capacity. Personally I'd like to see OCZ offer the option to enable RAISE, although I'm not sure if any user accessible utilities exist that would allow you to do that easily.
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 |
59 Comments
View All Comments
theagentsmith - Tuesday, May 24, 2011 - link
Corsair Force F115 154 Euros (1.34€/GB)OCZ Vertex 2E 120GB 175 Euros (1.46€/GB) don't know if it's a 25nm model
OCZ Agility 3 120GB 228 Euros (1.9€/GB)
OCZ Vertex 3 120GB 259 Euros (2.16€/GB)
Prices including VAT
Sure these new generation is faster, but there is barely any difference in a every day scenario, definitely not a night and day difference like a mechanical HD and a good SSD, so I prefer to pocket the savings to buy a F115 to another PC :)
OCedHrt - Tuesday, May 24, 2011 - link
Are the numbers in the "OCZ Vertex 3 240GB - Resiliency - AS SSD Sequential Write Speed - 6Gbps" chart on page 9 wrong? They don't match the conclusion: "The 240GB Agility 3 behaves similarly to the Vertex 3, although it does lose more ground after our little torture session."A 2-3% drop on Vertex 3 versus nearly 15% on Agility 3 is hardly behaving similarly. And the Agility 3 barely recovers after TRIM.
Mr Alpha - Tuesday, May 24, 2011 - link
For the TRIM test you fill the entire drive with incompressible randomly written data, and then TRIM it. It must take some time for the GC routine to actually clean up all those blocks. Does the time you wait before doing the after TRIM test affect the results you get?JasonInofuentes - Tuesday, May 24, 2011 - link
I think I understand what you're asking. You're wondering whether the time after the drive has been "deleted" and then left idle (for any amount of time) and thus allowed to engage in some amount of garbage collection, might be affecting the results. Certainly a possibility, which is why tests are run multiple times and averages reported.Great question, though. Thanks.
B0GiE - Tuesday, May 24, 2011 - link
I would like to see a 120Gb & 240Gb Shootout between the following:-Corsair Force Series 3
Corsair Force Series 3 GT
OCZ Vertex 3 Max IOPS
OCZ Vertex 3
OCZ Agility 3
Pretty Please!
icrf - Tuesday, May 24, 2011 - link
Agreed. I'm particularly interested in a 120 GB SSD, probably SF 2200 based. I bought an OCZ Vertex 2 @ 60G drive for boot/apps last fall, thinking I could stay within that, and have failed, so that's moved to the laptop and I'm looking for a 120G drive for the desktop.If the Corsair drives can really keep their pricing, they sound the most appealing. Specs sound very Vertex-like with pricing very Agility-like. I just want to see how some of these smaller drives fare with fewer NAND to deal with.
Oxford Guy - Tuesday, May 24, 2011 - link
The 240 GB Vertex 2!Shadowmaster625 - Tuesday, May 24, 2011 - link
"The original X25-M had 10 channels of NAND, giving it the ability to push nearly 800MB/s of data. Of course we never saw such speeds, as it's only one thing to read a few KB of data from a NAND array and dump it into a register. It's another thing entirely to transfer that data over an interface to the host controller."That's why I been saying they need to put a flash controller on the die. Imagine a dual sided DIMM with 8 NAND chips per side, each running ONFi 3.0 400MB/s. That's 6.4 GBps. zomg. It illicits a pavlovian response. 50 billion bits per second?
If intel was really interested in capturing the portable devices market, they'd be doing this. The tablet and smartphone SoCs all have integrated lpddr controllers, and look how fast they are for being such low bandwidth and low power.
bji - Tuesday, May 24, 2011 - link
I wonder if it's practical to put the controller on the die. Flash dies are highly optimized for flash, not general purpose processing transistors. Flash is usually a generation or so ahead of CPUs in the lithography process used because flash is simpler in its layout than CPUs. Putting a controller on a flash die would imply using the same lithography processes used for flash to be used for processing transistors and I just don't think that's likely to be feasable. Of course, flash controller logic would likely be alot simpler than a full x86 core. But I don't think that changes the fundamental impracticality of using flash process technology to create controller logic.bji - Tuesday, May 24, 2011 - link
Oh sorry I think I misunderstood you. You're talking about putting flash controllers on CPU dies, not on the flash dies, I think. In that case, I think that it's likely to be an inevitability. I predict that eventually permanent storage will look like DIMMs do now, like you said as sticks that you plug into slots in your motherboard just like you do for RAM now, and the controller will be built into the CPU to interface with them at high speed and operating systems will just see them as mapped to some memory range in the CPU address space. "Hard drives" will be a thing of the past, replaced by 'persistent memory'.