Steady State Performance (Worst Case) And TRIM
Clean Performance
In order to examine how an SSD might perform over time, we first fill up the user-accessible space with an incompressible sequential write, dirtying it up. The point is to replicate a worst-case situation where you find every available block written-to, leaving none free for the controller to use without first performing garbage collection.
Dirty Performance
Since all user-accessible blocks contain data, garbage collection (which includes wear-leveling) needs to kick in. At this point, in order to write to the drive, existing blocks need to be shuffled around. Over-provisioning is the reserved space where this is allowed to happen.
According to Iometer, we should expect just under 400 MB/s right out of the box in sequential reads and writes. Indeed, sequential writes aren't penalized at all. SandForce's technology does most of its garbage collection in the foreground, so peak write speeds remain optimal.
Yet, strangely, after filling the drive, compressible read performance falls to ~200 MB/s. This is weirdness. That reads suffer and writes don't really doesn't make sense. Although we can't pin a cause on this behavior, we spent hours retesting and confirming our results.
Rerunning this test with a 60 GB Vertex 3 yields the same results, suggesting that this is something we'd see from any SandForce-based SSD.
Torture Performance
There's one other steady state to consider, and it involves overwriting the original dirty state with 4 KB random writes. Because the drive is already full of data, the controller can't write to available blocks. When we start writing with sequential data again, we force garbage collection to occur. This is a far more strenuous exercise than the preceding test as a consequence of data fragmentation.
This exercise tends to emphasize background garbage collection, which, as we just noted, doesn't apply to SandForce. As a result, leaving the SSD idle won't help an SSD 520 as much as it might a Samsung 830, for instance.
Increasing data fragmentation on the drive causes compressible sequential reads to fall to 100 MB/s. This is what you'd see on any SandForce-based SSD though; it's not unique to Intel's.
TRIM Performance
Although idle time is less impactful on SandForce-based SSDs due to their foreground garbage collection, it is possible to recover compressible read performance by triggering the TRIM command. This occurs when you empty your Recycle Bin. Write speed still suffers because SandForce's controller delays block recovery until it actually needs to write.
Although idle time has less of an impact on SandForce-based SSDs due to their foreground garbage collection, it is possible to recover compressible read performance by triggering the TRIM command. This occurs when you empty your Recycle Bin. Write speed doesn't recover, however, because SandForce's controller delays the action until it actually needs blocks to write.
Fortunately, this may never be an issue for you. It only applies once you've written data to every block. And that's only likely to happen in an operating environment without TRIM support or if you RAID two SandForce-based SSDs together.
