Performance Degradation, Garbage Collection and TRIM
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. Therefore, contemporary SSDs usually try to free the memory in advance, and not when writes are underway. This usually happens in idle mode. At this time SSD controller can alleviate the performance drop almost completely by erasing unused flash memory pages ahead of time. The corresponding procedures are usually performed in idle mode, when the controller can fully restore the SSD performance by clearing out the unused flash memory pages. They use two techniques for that: idle-time garbage collection and TRIM.
An SSD controller doesn’t know which memory pages contain user data and which are considered empty by the OS. It happens this way because in file systems removing a file doesn’t involve its actual physical removal. Instead, the corresponding memory is marked in the file system as available for rewriting into. So, without involving the OS, 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 to this problem, modern OSes have the TRIM command which improves garbage collection the efficiency. TRIM provides the SSD controller with information on which data could potentially be removed without any harm, as it is considered unused by the OS. As a result, the SSD controller can increase the cleared pages pool by physically removing unneeded data so that the user didn’t feel a performance hit during subsequent write requests.
This is how it should be in an ideal world. In reality, however, SSDs differ in their garbage collection and TRIM implementation. 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 steady-state. This test follows the SNIA SSSI TWG PTS guidelines, which means that we measure the write speed in four cases one by one. 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. The following diagram shows the history of the relative speed changes, where 100% refers to the SSD performance in “fresh-out-of-box” state.
We want to point out the Plextor M5 Pro in the first place. As we mentioned above, we’ve got the Xtreme modification of this SSD which differs from the base version in improved garbage collection algorithms that are supposed to restore the SSD's performance even without TRIM. We’ve only seen one consumer-class product that can do that. It is Corsair's Performance Pro. And now Plextor’s M5 Pro Xtreme sports the same capability. It is going to be perfect for non-TRIM environments.
As for the Toshiba THNSNH256GCST, it still doesn’t betray any relation to Marvell, so we can even suspect that the word “Marvell” is added on its controller just for show. This SSD can return to its original performance level after receiving the TRIM command from the OS but otherwise its performance is not restored. In other words, the garbage collection algorithms do not work unless aided by the OS, even though the SSD has a reserve pool of 7% of its total storage capacity.