Degradation and Steady-State Performance
Unfortunately, SSDs are not always as fast as in their “fresh” state. In most cases their performance goes down after some time and in real life we deal with completely different write speeds than what we see on the diagrams in the previous chapter of our review. The reason for this phenomenon is the following: as the SSD runs out of free pages in the flash memory, its controller has to clear memory page blocks before saving data into them, which causes substantial delays. Although, modern SSD controllers can alleviate the performance drop by erasing unused flash memory pages ahead of time, when idle. They use two techniques for that: idle-time garbage collection and TRIM.
Of course, users are more interested in the consistent performance of their SSDs over a long period of time rather than the peak speed they are going to see only during the initial short-term usage period, while the drive is still “fresh”. The SSD makers, however, declare the speed characteristics of “fresh” SSDs for marketing reasons. That’s why we decided to test the performance hit that occurs when a “fresh” SSD becomes a “steady” one.
To get a complete picture of SSD performance degradation we ran special tests based on the SNIA SSSI TWG PTS (Solid State Storage Performance Test Specification) methodology. The main idea of this approach is to measure write speed consecutively in four different cases. First we measure the “fresh” SSD speed. Then we measure the speed after the SSD has been fully filled with data twice. The third test occurs after a 30-minute break during which the controller can partially restore performance by running the idle-time garbage collection. And finally, we measure the speed after issuing a TRIM command.
We ran the tests in synthetic IOMeter 1.1.0 RC1 benchmark, where we measured random write speed when working with 4 KB data blocks aligned to flash memory pages at 32 requests queue depth. The test data were pseudo-random.
As we’ve noted in our earlier reviews, SSDs with second-generation SandForce controllers are more susceptible to performance degradation than, for example, SSDs with Marvell or Indilinx controllers. The OCZ Petrol doesn't offer anything new in this respect. Its performance lowers by a factor of 8 as it gets filled up by data. Its own garbage collection doesn't help much, but the TRIM command restores the Petrol back to its original speed. The TRIM implementation in the Indilinx Everest controller is almost perfect: any SSD based on that hardware platform can be restored back to its original performance. We mean this Petrol as well as the Octane and Vertex 4 SSDs we covered in our previous reviews.
The efficient TRIM can improve our opinion about the Petrol's speed because its SandForce-based opponents can never be restored to their out-of-box state. The write speed tests in the previous section of our review reflect the out-of-box performance and you can see the SSDs’ write speed degradation in the next diagram, as measured with CrystalDiskMark 3.0.1.
We’ve got a different picture with sequential writing now. The steady-state Petrol is unexpectedly ahead of all of its opponents with second-generation SandForce controllers. On the other hand, it is so slow with small chunks of data that even its perfect TRIM implementation can't save the day.
Generally speaking, the Petrol’s behavior reminds us of the Octane. Sharing the same Everest controller, they have the same highs and lows. The difference is that the Octane is overall faster than the Petrol, running on NAND flash memory with synchronous interface.