Results: The Vector 150's Performance Quirks
Performance Vs. Capacity
I really like HDTune Pro. It's a decent canned storage test full of helpful tools. The utility is great for evaluating hard drives, and a little less relevant to SSDs. The software's most prominent feature is its ability to write and read to the entire surface of a storage device. When you're testing rotating media, it's easy to observe speed dropping as measured from the outer to inner tracks. That's just physics. With SSDs, the "surface" is the drive's entire capacity, minus over-provisioning or spare area.
Now, there are good reasons to use HDTune for reviewing SSDs, but there are serious limitations to be aware of as well. Most strikingly, HDTune writes in easily compressible zero-fill data, which isn't particularly useful for testing SandForce's technology. Also, I want more control over how the utility does its job. So, I created my own script-based version to do what I need.
This little tool is especially helpful for testing OCZ's newer offerings because they are able to take the capacity of a given drive and use it in a way that emulates single-level cell NAND in a manner of speaking. We think the mechanism works with faster pages for as long as it can, delaying the use of slower pages. This is why the Vector, Vertex450, Vertex 4, and Agility 4 prefer to write to the faster half of the flash. It's easiest to demonstrate that unique behavior by charting performance over capacity.
Starting with a freshly erased drive, we write to the entire capacity and display our results as a percentage of the capacity. I separate the 240 GB SSD into sequential chunks 1/200th of the total capacity. Then, each segment's average throughput is displayed as a data point representing 0.5% percent of the "surface". In this case, the Vertex 3.20 and Vector 150 are the same size (240 GB), while the Vertex 450 and Vector are 256 GB. The larger the addressable capacity, the more bytes it takes to equal one 0.5% chunk.
We want to write sequentially, so we're sticking with 1024 KB access sizes and a queue depth of one. Higher queue depth activity isn't always truly sequential in the strictest sense of the word.
From the beginning, OCZ's Vector, Vector 150, and Vertex 450 are neck and neck until just past the 50% mark. After that, the Vector 150 extends even further before dropping into sub-200 MB/s territory. Once all of the fast pages are gone, the drive has to write to the slower-to-program pages that comprise half of the flash. Once the speed stabilizes again, the Vector 150 outpaces (by a few MB/s) the Vector, which in turn is above the Vertex 450.
Also included in our chart is the Vertex 3.20. OCZ's 240 GB SandForce-based drive is being fed random data. But notice the lack of performance variation as the drive is written. Also, the Vertex 3.20 falls right around the average speed of OCZ's Indilinx-infused SSDs if you consider their whole capacity. This is a good reality check that represents the behavior of most other drives.
Theoretically, if we were to fill 60% percent of the drive with real files (say an operating system and a few games), the SSD would write that data as quickly as possible to the faster pages. Then, over time, it'd shuffle around that data, freeing up some portion of the remaining faster pages for new tasks. We can't say for certain that the process works this way; OCZ is tight-lipped about its mechanism, and we're left with educated guesses.
So why does the Vector 150 maintain its excellent performance longer than the other two Barefoot-based SSDs? The answer lies in the additional over-provisioning. The Vector 150 uses 16 GB more over-provisioning than the Vector and Vertex 450. Sixteen gigabytes is 6.25% of 256 GB, so it's possible that the Vector 150 can go around 6% deeper without slowing down to sub-200 MB/s levels.
