Page 1:Is There A Problem Here, Sir?
Page 2:Lost Capacity: Defining And Explaining The Scope
Page 3:Lost Performance: Not Just A Figment Of Your Imagination
Page 4:Test Setup And Benchmarks
Page 5:Benchmark Results: I/O Performance
Page 6:Benchmark Results: Iometer Streaming
Page 7:Benchmark Results: CrystalDiskMark Streaming Performance
Page 8:Benchmark Results: 4 KB and 512 KB Random Reads
Page 9:Benchmark Results: 4 KB and 512 KB Random Writes
Page 10:Benchmark Results: PCMark Vantage Storage Test
Page 11:Conclusion: OCZ’s Sin
Lost Performance: Not Just A Figment Of Your Imagination
There are a number of reasons why 25 nm asynchronous flash can be slower than 3x nm flash. These reasons don’t apply to synchronous flash—the stuff you’ll see on the upcoming Vertex 3 drives from OCZ.
The number one reason that performance drops is the need for more error correction on the 25 nm node. This is related to the fact that the smaller geometry sustains fewer program/erase cycles. Error correction imposes processing overhead, though. I have to assume that OCZ, on its 25 nm-based SSDs, has to bolster the error correction it’s doing, impacting performance. Basically, near-term the company is taking a hit so that 5000 P/E cycles out, when uncorrectable bit read errors become a concern, SandForce’s RAISE technology can cope with and fix them.
The conclusion here isn’t completely random. While working on my benchmark results, I shared some of what I was seeing with OCZ. I noticed that streaming performance in Iometer was consistent from the 34 nm to 25 nm drives. It was only once we started hacking around with the 4 KB random reads/writes and benchmark patterns that performance dropped. Well, that’s precisely where processing overhead would come into play with an architecture like SandForce’s, which tries to work as efficiently as possible by mashing data together and sending it sequentially.
The company promised to supply an experimental firmware, which is by no means ready for public consumption, but is designed to address my concerns. I don’t have specifics on what the firmware does other than alleviate processing overhead a bit. But my guess is that it either dialed back the aggressive ECC or optimized the new algorithm being used. The optimization in the first iteration is relatively minor, but OCZ claims there is a lot more it can do to narrow the performance gap we’re observing currently. Do I think it's a coincidence that SandForce's second-gen controller family is also getting more advanced ECC? Not at all.
Now, consider the alternative to what OCZ is doing. Another vendor building SandForce-based drives using 25 nm flash (this is going to include everyone soon, by the way; the shift is happening industry-wide) can maximize performance today without bolstering ECC—risking outright drive failures in the future. Of course, we can’t put that to the test until our 25 nm drive see more extraneous use. But it's a scary thought. Serve up better numbers today, cross your fingers, and hope failures don't become epidemic three years from now? I certainly hope not.
What I do have currently is a run-down of a true apples-to-apples comparison: two 120 GB Vertex 2s, each with 16 chips, representing the 34- and 25 nm-based NAND devices.
- Is There A Problem Here, Sir?
- Lost Capacity: Defining And Explaining The Scope
- Lost Performance: Not Just A Figment Of Your Imagination
- Test Setup And Benchmarks
- Benchmark Results: I/O Performance
- Benchmark Results: Iometer Streaming
- Benchmark Results: CrystalDiskMark Streaming Performance
- Benchmark Results: 4 KB and 512 KB Random Reads
- Benchmark Results: 4 KB and 512 KB Random Writes
- Benchmark Results: PCMark Vantage Storage Test
- Conclusion: OCZ’s Sin