Performance Degradation, Garbage Collection and TRIM
Unfortunately, SSDs are not always as fast as in their fresh out-of-box state. In many situations their real-life performance goes down far below the numbers you have seen in the previous section of this review. The reason is that, having run out of free pages in flash memory, the SSD controller has to erase memory pages before writing to them, which involves certain latencies. Modern SSD controllers can alleviate the performance hit by erasing unused flash memory pages beforehand when the SSD is idle, which is the key idea of the Idle-Time Garbage Collection algorithm whose implementation has a strong effect on the real-life performance of any SSD.
An SSD controller doesn’t know which memory pages contain user data and which are considered empty by the OS. It’s because removing a file doesn’t involve its actual physical removal. Instead, the corresponding memory is marked in the file system as available for writing into. So, an SSD controller can only pre-erase pages in the reserve pool (if it exists) which is not accessible by the OS. For a better solution of this problem, modern OSes have the TRIM command which improves garbage collection efficiency. TRIM enables the SSD controller to physically remove unneeded data so that the user didn’t feel a performance hit during subsequent write requests.
This is how it should be theoretically. In practice, however, SSDs differ in their garbage collection and TRIM support. That’s why we check out the performance hit an SSD suffers when transitioning from its out-of-box (the flash memory is clean) to used state. This test follows the SNIA SSSI TWG PTS guidelines, which means that we measure the speed of writing in four cases one by one: 1) when the SSD is in its out-of-box state, 2) after the SSD has been twice filled full with data, 3) after a 30-minute pause that allows the SSD controller to restore performance by means of data reorganization and garbage collection, and 4) after the SSD is cleaned logically by the TRIM-supporting OS.
So we use IOMeter 1.1.0 RC1 to measure the speed of writing random-address 4KB data blocks aligned to flash memory pages at a request queue depth of 32. The test data are pseudo-random. The changes in speed are shown in the next diagram where 100% is the SSD’s out-of-box performance.
The firmware for OCZ’s new drives with Toshiba flash memory has a new implementation of the garbage collection algorithm, which has become more aggressive and doesn't rely on the OS. The reserve pool of flash memory inaccessible by the user is increased from 7 to 14% in the new SSDs, so we can see that both of them can fully restore their performance during an idle period without a TRIM command. OCZ’s earlier SSDs showed the same behavior, but the improved garbage collection algorithm makes the new SSDs comparable to the Plextor M5 Pro in this respect.
On the other hand, most of the modern OSes support the TRIM command, which is equivalent to Secure Erase but doesn’t destroy data. Thus, the Vector 150 and the Vertex 460 restore their performance blamelessly. The performance degradation problem is not likely to bother their users.
OCZ drives are also susceptible to another performance degradation effect. It occurs when the drive gets filled with data by more than 50%. Typical of Indilinx firmware, it persists in the Vector 150 and Vertex 460, too. The performance hit can be revealed easily by benchmarking the speed of writing data sequentially until the SSD is filled up. Here’s the speed graph of the Vector 150 (the Vertex 460 would have the same graph):
As you can see, the write speed drops as soon as half of the storage capacity is filled with data, just like on the earlier SSDs from OCZ. This is due to the Barefoot 3’s ability to access MLC NAND flash in SLC mode and the controller does so whenever possible. Storing 1 instead of 2 bits of data in each flash memory cell can be done with lower latencies to improve performance. But when all flash memory cells already contain 1 bit of data each, it is necessary to switch them to MLC mode, which leads to the above-mentioned performance hit.
The performance hit is not irrecoverable, however. The writing performance will be restored back to the normal level as soon as the SSD gets some idle time. So, you will only be able to see this effect if you write a lot of data (over half of the SSD's total capacity) in a single continuous session. And again, the SSD will restore its writing performance after a brief idle period during which the controller can reorganize data in the flash memory.