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.
The SanDisk Ultra Plus is based on a Marvell controller, so we have no reason to suspect any problems with its garbage collection algorithms. And that’s indeed so. The TRIM command restores this drive’s performance to its original out-of-box level. Its background garbage collection is not so efficient, though. Plextor SSDs with Marvell controllers are much better in this respect. There’s a simple explanation: the SanDisk Ultra Plus has a small reserve pool, most of which is utilized for the nCache technology. So if you’re going to use this SSD in a non-TRIM environment, you may want to leave some of its storage space unpartitioned to improve its background garbage collection.