Examining Steady State Performance (Worst-Case)
Clean Performance
Determining how an SSD is expected to perform over time requires “dirtying” it by filling user-accessible space with an incompressible sequential write. The point is to replicate a worst-case situation, where every available block has been written-to, leaving nothing free for the controller to use without first performing garbage collection.
Torture Performance
Worst-case steady-state performance testing involves writing over a full drive with 4 KB random writes. Because the drive is already packed, the controller doesn't have any empty blocks available. Writing again with sequential data forces garbage collection to occur, making this a far more strenuous exercise than the preceding test. This is important aspect of performance to inspect because it confirms the existence of efficient garbage collection. Because the Vertex 4 doesn't dedicate any capacity to over-provisioning, it's an especially critical metric to run.
We noticed that the original Everest controller (used to drive the Octane) primarily employed foreground garbage collection. That isn't the case with OCZ's Vertex 4.
The graphs above and below reveal a nice gradual performance recovery as garbage collection kicks in. Of course, in the real world, you probably won't see such an extreme situation where all blocks are dirty. More likely is that you'll have some free space available for the controller to use during idle periods for garbage collection. Combined with regularly emptying your Recycle Bin, triggering the TRIM command, you're almost assured to not see our worst-case scenario.
