Degradation and Sustained Performance
Unfortunately, SSDs are not always as fast as in their “fresh” state as they should be. 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. On the other hand, modern SSD controllers can alleviate the performance hit 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. 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 in four different cases. First we measure the “fresh” SSD speed. Then we measure their 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.
According to our earlier tests, SSDs with second-generation SandForce controllers are more susceptible to performance degradation than, for example, their Marvell-based counterparts. The Octane doesn’t bring anything new in this respect. Its performance drops by a factor of 6 as it gets filled with data. The garbage collection technique doesn’t prove to be effective because the reserve pool is small at only 7% of the total storage capacity. The TRIM command, on the contrary, brings the Octane back to life. The Everest can boast an excellent TRIM implementation as the performance of the SSD returns to its original level. The Indilinx developers have managed to beat their SandForce counterparts in this respect.
TRIM improves our impression of the Octane’s speed. The write speed results you have seen in the previous section are only reflective of the performance of the SSDs in their “fresh”, out-of-the-box state. But as they get filled with data and become “used”, their performance can change. The write speed of the used SSDs, as measured with CrystalDiskMark 3.0.1, is shown in the next diagrams.
The SandForce-based SSDs slow down after a while and cannot be returned to their original speed even with the TRIM command, yet the overall picture doesn’t change. The Octane is so slow at processing small data blocks that even its perfect TRIM implementation cannot save the day. It does enjoy an even larger advantage at sequential writing, though.