OCZ Octane 1.13 Firmware Update: Improving 4KB Random Write Performance

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:

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