The one thing that OCZ has been missing for so many years is finally one of its staples: focus. The same company that dabbled in everything from brain mice to DIY notebooks is now almost exclusively an SSD company that peddles power supplies on the side. OCZ's penchant for aggressively trying new things hasn't faded away however. As an SSD maker, OCZ is currently or will in the near future, be shipping drives based on controllers from three different vendors - each with their own strengths. OCZ's relationship with SandForce continues and the Vertex 3 remains OCZ's highest performing offering. A recent partnership with Marvell gives OCZ early experience with native PCIe based SSDs, experience that is extremely important as the industry marches towards a new PCIe based interface standard for SSDs (SATA Express). Finally there's OCZ's own controller, the Indilinx Everest, which it is quickly building momentum behind. It's obviously in OCZ's best interests to have its own controllers in the bulk of the drives it makes, but one doesn't simply build a better controller than everyone else on the first try.

Everest has promise. Its overall performance is competitive with SandForce based solutions, but the architecture has real limitations when it comes to long term random write performance. In my own internal tests I measured a worst case write amplification of over 50x in high queue depth 4KB random writes. The chart below gives you an idea of estimated write amplification for a number of controllers in a highly random workload:

Estimated Worst Case Write Amplification

In our reviews of OCZ's Everest based Octane SSDs I mentioned that the high write amplification is really only an issue for enterprise workloads. As OCZ has high aspirations for being a player in the enterprise SSD space it's clear that work needed to be done to make Everest enterprise-worthy.

At CES OCZ showed me Everest 2, which it claimed would get write amplification down to around 10x. OCZ wouldn't go into specifics other than to say that it would come through a combination of firmware and controller improvements. With Everest 2 due out this summer, I figured we wouldn't see much progress on the Everest 1 front in the mean time. I was wrong.

A few weeks ago OCZ released a firmware update for its Octane drives that promised a significant increase in 4KB random write performance. The Octane's original 4KB random write performance wasn't all that high but it was good enough for most client workloads. The thing to keep in mind when it comes to random performance is that even the best hard drives are only good for a couple hundred random IOs per second. Any client workload that required close to a hundred thousand IOPS would simply be non-functional on any hard drive based systems. Instead, being able to deliver around 20 - 40K IOPS seems to be the sweet spot for client SSDs until we move to an all-SSD world and developers can really begin to take advantage of all of the available IOPS on these drives.

Doubling random IO performance would surely make benchmarks look better, but I suspect this new firmware has more to do with Everest 2 and preparing for an entry into the enterprise market rather than improve the client Octane experience. Indeed if you look at estimated write amplification when running a highly random workload, the new firmware has a huge impact on existing Octane drives. While it's not quite as low as I'd like, it's clear that the new firmware is better if you're running a high queue depth, highly random workload. Precisely the sort of thing an enterprise customer would be looking for.

You can update the Octane's firmware from within Windows using OCZ's toolbox, provided it's not your OS/boot drive. There's no support for alternate flash routes at this point, although OCZ says a Linux based updater is coming.

OCZ starts off by warning you that firmware 1.13 is a destructive flash. There are a number of reasons why an SSD update would get rid of all of your data, ranging from sloppy coding all the way up to significant firmware architecture changes. If you change the way LBAs are mapped to NAND pages you're posed with an interesting problem. Do you wipe the existing mapping tables and start from scratch, guaranteeing the best possible performance, or do you attempt to slowly migrate the old mappings to the new layout, preserving data but potentially significantly reducing performance? Users of the original X25-M may be familiar with the impacts of the latter. If you had a lot of data on your X25-M and ran the first major update, you would've noticed much higher latency IO as the drive attempted to reorganize parts of itself with every write. If OCZ shifted the balance of its hybrid page/block mapped architecture a bit, mapping more LBAs directly to NAND pages, it was likely easier to just rebuild the tables rather than deal with the extra work involved with migrating architectures with live data.

OCZ's toolbox tries to determine whether or not your Octane is a boot drive by looking at the drive id number enumerated by your system. The theory is that drive 0 should be your boot drive, while everything else is expendable. This is obviously a flawed theory as drive enumeration depends on more than the simple choice of SATA port. It's possible to have a secondary drive be detected first and thus appear to be drive 0 to Windows. If this happens, and your secondary drive is enumerated as drive 0, OCZ's toolbox won't allow you to update the firmware. The easiest way around this limitation is to simply boot your drive without a SATA cable attached (leave power attached) and just plug the drive in after you're in Windows. Obviously notebook users are out of luck as this method won't work, although you could try hot plugging your drive while your notebook is on (you could theoretically damage your drive this way, proceed at your own risk). While this gets you around the drive 0 limitation, the toolbox won't see your drive if you have Intel's RST drivers loaded - you need to be using Microsoft's AHCI drivers. I get that OCZ doesn't have quite the software engineering staff that Intel and Samsung do, but both of those companies allow their toolboxes to work with Intel's drivers installed and as a competitor OCZ needs to offer a similar user experience.

With all of the requirements met and the Octane showing up as drive 1, I was able to upgrade the firmware. OCZ changed its firmware numbering schema, this new update is now version 1.13 compared to 1463, its immediate predecessor. Midway through the update you'll get this message:

Ah ha! OCZ is changing its LBA mapping algorithm. After waiting a couple of minutes for the tables to finish mapping, you need to shut down your machine (a soft reset never works for me with the Octane and firmware updates) and power it back on. After all of this, the Octane is now up to 1.13 and I could begin testing.

Given the focus of the update was to address small block random IO it's likely that OCZ moved to a more granular mapping algorithm where each LBA now maps either directly to a single NAND page or a smaller group of pages. Another alternative would be if OCZ is using a hybrid page/block mapping algorithm where only a percentage of LBAs are page mapped while the rest are mapped to blocks. If this is the case then OCZ could have simply adjusted the balance between page and block mapped LBAs. The final option is a combination of the two possibilities.

Seeing as how the Octane has a ton of DRAM on-board (512MB) the controller should have no problems maintaining sequential performance even with more mapping entries to keep track of. Let's look at the numbers to see how the new firmware changes things.

The Test

CPU

Intel Core i7 2600K running at 3.4GHz (Turbo & EIST Disabled) - for AT SB 2011, AS SSD & ATTO

Motherboard:

Intel DH67BL Motherboard

Chipset:

Intel H67

Chipset Drivers:

Intel 9.1.1.1015 + Intel RST 10.2

Memory: Corsair Vengeance DDR3-1333 2 x 2GB (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 & Sequential Read/Write Speed
Comments Locked

23 Comments

View All Comments

  • iwod - Thursday, February 9, 2012 - link

    Get M4 ( Or Marvell Based ) if you want Stable and Top Notch Performance.

    Get Sandforce Based Drive if you only care about Performance.
  • Samus - Friday, February 10, 2012 - link

    Don't forget Sandforce is generally cheaper, especially their mature first-gen controller based drives like the $120 Sandisk 120GB, or recentlky the Patriot $105 120GB drive.
  • Ammaross - Friday, February 10, 2012 - link

    "...or recently the Patriot $105 120GB drive. "

    The Patriot Pyro you're mentioning is based on a Sandforce 2281 controller, so SATA3 and second-gen. But yes, definitely cheaper than most (all) worthy alternatives.
  • GrizzledYoungMan - Friday, February 10, 2012 - link

    Sorry, but no. I just RMA'ed a 128 gb Crucial m4 because of a numerous issues and incompatibilities stemming from poor firmware. The system wouldn't wake from sleep without modifying the registry (and even then, it wouldn't always work) and the drive would frequently stutter thanks to an unacknowledged (but clearly prevalent, given forum posts about it) issue with Intel RST 10.x drivers.

    I am now running a 120 gb Intel 320 and loving it. The performance is indistinguishable from the m4, despite the latter's advantage in spec and benches. If anything, the 320 might feel a bit snappier than the m4 (and certainly better than my old 60 gb Vertex... not 2 or 3, just Vertex).
  • iwod - Friday, February 10, 2012 - link

    I can definitely say the performance IS distinguishable from m4 and Intel 320.

    In terms of stability Intel is in a different league. So i forgot to mention them.

    M4 may have its problem, but nothing compare to Sandforce.
  • ckryan - Friday, February 10, 2012 - link

    OCZ deserves credit for continuing to support it's older Indilinx drives with newer FW. While Arrowana FW never materialized for Intel NAND equipped models, their newer FWs are much better.

    The problem with the Octane isn't necessarily it's performance. The problem is price.

    Unless the price drops, there isn't a compelling reason to own one. I'm pleased that OCZ is releasing new FW that positively impacts performance, but until they get the price lower, I wouldn't recommend that shoppers pass up the 830 -- especially at 128GB. Depending on the day, the Samsung 830 128GB is $10 to $20 more. For that price differential, you get better performance and probably better NAND as well.

    Correct me if I'm wrong, but I think the 64GB 830 and 128GB Octane are pretty much equal performance-wise.
  • pc_void - Friday, February 10, 2012 - link

    The octane isn't an older drive. It came out not long ago.
  • ckryan - Friday, February 10, 2012 - link

    No, I mean it's awesome that OCZ is supporting the original Indilinx with newer FW (like 1.7, and I assume there will be at least one more FW release). OCZ does a lot of things which irritate me to no end, but FW support is not one of them.

    To me, FW support (both initial and long term) is pretty important, so they deserve credit for that.

    The 128GB Octane is actually more expensive than the 128GB 830 today; Newegg is having a sale.
  • pc_void - Friday, February 10, 2012 - link

    Do see what your saying now.
  • eman17j - Monday, February 13, 2012 - link

    OCZ bought the indilinx controller thats why its in the octane and thats why they are supporting it. It is their own controller. They arent just trying to help out by supporting some old controller

Log in

Don't have an account? Sign up now