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.

A few weeks ago OCZ released a firmware update for its Octane drives that promised a significant increase in 4KB random write performance. Read on for our analysis of the firmware update!

]]>

OCZ's Indilinx Everest 2 Launching in June 2012, Features Vastly Improved Random Performance

OCZ has a lot to show off this year at CES/Storage Visions, but the most exciting product from a client standpoint is its new Everest 2 controller. While the original Everest just launched two months ago, Everest 2 is expected in the next 6 months. OCZ already has silicon back and it is fast. 

Whereas Everest 1 was a competitive performer, Everest 2 is designed to really go after the performance crown. OCZ has focused more on small block performance as well as reducing write amplification, both issues I've brought up regarding the current Everest in our reviews of OCZ's Octane. Everest 2 is an updated controller (IDX400M00-BC vs. IDX300M00-BC) with a new firmware architecture designed to address these shortcomings. Both it and the original Everest controller will co-exist in the market for a period of time, but the Everest 2 will clearly be aimed at the high end. Target performance is around 550MB/s sequential reads, 500MB/s sequential writes and 90K 4KB random write IOPS (the Iometer screenshots in the gallery below show early 4KB Random Write and 128KB Sequential Write performance, using our own Iometer tests, in that order). If OCZ ends up really confident in the Everest 2, it might just end up being the heart of the Vertex 4...

Gallery: OCZ's Indilinx Everest 2 Launching in June 2012, Features Vastly Improved Random Performance

]]>

Correction: OCZ Vertex 3 Random Read Performance Data

A huge thanks goes out to AnandTech reader Andrei and some very attentive Xtreme Systems forum members. I just got an email pointing me to this thread where one particular number from our OCZ Vertex 3 and Intel SSD 510 articles was called into question. The problem? The 4KB random read numbers for the Vertex 3 were supiciously high. The reality? They were incorrect. 

I was just alerted to the error and quickly powered up the SSD testbed to recreate the test. It looks like the original numbers were either run at a queue depth of 32 or accidentally copied from one of the runs of 4KB random write tests. Either way the number was incorrect and has been fixed in all affected articles.

The updated numbers don't change our conclusions. The Vertex 3 is still the fastest next-generation SSD we've tested thus far and it still maintains a random read performance advantage over the Intel SSD 510.

The integrity of our test data is something we all take very seriously here. Errors like these do you a disservice and hurt the reputation I've worked so hard over the past 14 years to build. I do hope this oversight hasn't negatively impacted your opinion of AnandTech - we aren't perfect, but we strive to be. I do apologize to all of you for the error and I will be restructuring how I run and record my Iometer tests to avoid this particular issue from cropping up again. 

My sincere thanks goes out to Andrei and the XS folks who helped track down the error and inform us of its existence.

]]>