Page 1:OCZ's Octane SSD Taps Indilinx For Performance
Page 2:Indilinx's Everest Controller Does 6 Gb/s
Page 3:Test Setup And Firmware Notes
Page 4:Benchmark Results: Storage Bench v1.0 And PCMark 7
Page 5:Benchmark Results: 4 KB Random Performance
Page 6:Benchmark Results: 128 KB Sequential Performance
Page 7:Sequential Performance Versus Transfer Size
Page 8:Performance Over Time And TRIM
Page 9:Octane: A Portent Of What's To Come From OCZ
Page 10:Storage Bench v1.0, In More Detail
Page 11:More Background On Our Benchmarks
Performance Over Time And TRIM
Examining how a drive might perform over time isn't difficult. First, we fill up the user-accessible space using a sequential write, making the drive "dirty." Then, we overwrite that data using a 4 KB random write pattern. Because the drive is full of data, though, garbage collection can't consolidate the drive's scattered pages into free blocks. When we start writing over with sequential data again, the effects of active garbage collection kick in.
20 Minutes Of Random Writes
QD=4 For 20 Minutes, No Recovery
According to Iometer, sequential read/write performance should be 340/260 MB/s fresh out of box. Yet, after filling the drive with sequential data, hammering it for 20 minutes with random data, and the writing sequentially to it again, the performance story is quite a bit different. While sequential writes start at 250 MB/s, they quickly drop to 6 MB/s.
The point of this exercise, as accelerated as it is, is to replicate the worst-case situation in which you'd find yourself after writing to every available block, leaving no free blocks for the controller to use a scratch space.
QD=4 For 20 Minutes, 1 Hour Idle
If you introduce some idle time, Octane slightly recovers performance, but we're still dealing with a sequential write speed around 40-50 MB/s.
30 Minutes Of Random Writes
We already know that, even fresh out of its box, Octane's random performance is lower than most of today's modern 6 Gb/s drives. As a result, it's impossible to make all of the blocks "dirty" after 20 minutes of random writes using a queue depth of four. The remaining "clean" blocks end up obscuring what would become a more notable issue.
If we rerun the test with a queue depth of 32 and hammer the drive for 30 minutes, amplifying our previous experiment, performance drops to 7 MB/s and stays there. No matter how long you let the drive sit idle, hoping for background garbage collection to kick in and clean things up, it doesn't recover its performance. This is an issue with the Octane that we asked OCZ to comment on, but received no response. Dirty the drive completely and it appears to be toast.
Remember a few pages back where we told you that OCZ doesn't set aside any of the Octane's NAND for over-provisioning? Crucial does the same thing with its m4, only it's able to recover more gracefully from a completely dirty state. What, then, could be the issue with Octane?
It might seem to make sense that creating a smaller-than-full partition on OCZ's drive could be a solution, manually over-provisioning it. The solution to Octane's problem isn't as simple as setting aside a little bit of unpartitioned capacity to emulate over-provisioning. Check out the diagrams below:
512 GB Octane: 2.5% Over-provisioning
512 GB Octane: 50% Over-provisioning
When we manually specify over-provisioning, the controller is able to actively free up space after the drive gets hammered with random writes. There is one catch. The amount of space the drive is able to make available for "like-new" write performance is proportional to what you over-provision. In the first diagram, we manually set 2.5%, and performance is solid for about that long. In the second diagram, half of the drive is set aside for over-provisioning, and in that case, its performance persists.
The thing is, nobody is willing to set aside half of their 512 GB SSD so that, when the drive is filled with data, performance doesn't fall off. Thus, the only real way to avoid the pitfalls of Everest's garbage collection shortcomings is to make sure you're using a system able to utilize the TRIM command. That means avoiding these things in RAID or on an older operating system.
|Transferring H.264 Movie|
Average Write Speed
|Clean Performance||Dirty Performance|
|No Over-provisioning||~ 250 MB/s||~ 7 MB/s|
|2.5% Over-provisioning||~ 250 MB/s||~ 10 MB/s|
|50% Over-provisioning||~ 250 MB/s||~ 250 MB/s|
Here's the same sort of experiment, related in real-world terms rather than less-tangible HD Tach stuff. The difference between our "clean" and "dirty" drive with over-provisioning in place is crystal clear when we write a 32 GiB Blu-ray rip to the drive. Without an abundance of over-provisioning, the transfer rate becomes extraordinarily slow.
We already know that, if you let the Octane sit idle, it's only able to partially recover its performance. However, if you empty your Recycle Bin in Windows, triggering the TRIM command, speeds recover fully, as illustrated in the above diagram.
- OCZ's Octane SSD Taps Indilinx For Performance
- Indilinx's Everest Controller Does 6 Gb/s
- Test Setup And Firmware Notes
- Benchmark Results: Storage Bench v1.0 And PCMark 7
- Benchmark Results: 4 KB Random Performance
- Benchmark Results: 128 KB Sequential Performance
- Sequential Performance Versus Transfer Size
- Performance Over Time And TRIM
- Octane: A Portent Of What's To Come From OCZ
- Storage Bench v1.0, In More Detail
- More Background On Our Benchmarks