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. Although, modern SSD controllers can alleviate the performance drop by erasing unused flash memory pages ahead of time, when idle. 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’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 the efficiency of garbage collection. 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.
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.
As you can see in the diagram, the performance degradation problem only persists on SandForce-based SSDs. The others can restore their speed back to the original level after a TRIM command. That’s why the Kingston SSDNow V300, like all other SF-2281 based solutions, are better suited for a system disk rather than for storing user data. When files are constantly being rewritten, the SSD’s writing performance may plummet by a half, which is most annoying.
Background garbage collection doesn’t work well on the SandForce-based SSDs, too. Although they have a rather large reserve pool, their speed can only be restored, even though partially, in a TRIM-supporting environment. This remark is important for Windows XP (where TRIM isn’t supported at all), for Mac OS X (when you have to enable TRIM), and for RAIDs (where TRIM depends on the RAID controller’s driver).