Quantifying the block-rewrite penalty
Before digging into our benchmark results, it's worth taking a moment to quantify the magnitude of the block rewrite penalty associated with each drive. As we've seen in the past, some SSDs deal with this issue better than others.
First, we used an IOMeter workload consisting exclusively of 4KB random write requests to measure the response time of each drive in its factory-fresh state, with no occupied flash pages. We then subjected each SSD to several runs through HD Tach's "full" disk benchmark, whose write speed test fills drives with a single, contiguous file. This test neatly occupies all available flash pages, forcing a block rewrite for every subsequent write request.
With our SSDs now in a simulated used state, we ran our IOMeter random writes test once more to gather response time data.

All the drives have much quicker response times when fresh than in a simulated used state. The performance differences vary from one drive to another, though. The Vertex's response time rises by nearly an order of magnitude, while the X25-M is only about five times slower. Neither compares to the Summit, whose used-state response times are roughly 20 times higher than with a fresh drive.
In addition to exhibiting the greatest disparity between fresh and used response times, the Summit is easily slower in each state than the Vertex and X25-M. Those two drives offer nearly identical used-state response times, although the fresh Vertex is quicker than the Intel drive in the same condition.
Based on these results, the Summit and its underlying Samsung controller seem to be the most adversely affected by the block-rewrite penalty, at least in this synthetic test. The Vertex and X25-M, on the other hand, look pretty evenly matched when in a used state. Keep in mind that the benchmark results on the following pages were all obtained with the drives running in our simulated used state.
| Friday night topic: The trouble with Best Buy | 143 |