Performance Comparisons – TRIM Speed

Thanks to the plethora of data we have at our disposal from the new suite, I can derive some additional interesting data that nobody seems to have been paying any attention to yet. Have you ever deleted a large file and then noticed your system seem to hang for some time afterward? Maybe file moves from your SSD seemed to take longer than expected?

trim-0.png

That's your problem right there. In the above capture, a 16GB file was deleted while a minimal level of background IO was taking place. Note how that IO completely stalls for a few seconds shortly after the file was deleted? That's a bad thing. We don't want that, but to fix it, someone needs to measure it and point it out. Enter another aspect of our new testing:

trim-1.png

Latency Percentile data was obtained while running a 'light' (1000 IOPS) workload in the background while files of varying sizes were deleted. The amount of latency added during the deletions was measured, compared with a baseline, and correlated with the sizes of the deleted files. The result is how much latency is added to the active workload per GB of file size that was deleted. In short, this is how long you may notice a stutter last after deleting a 1GB file.

To avoid confusion, I've maintained the performance-based sort from the mixed test for these charts. Here you can tell that some drives that did perform well on that test stick out a bit here when it comes to how they handle TRIM. Ideally, these results should all be as close to 0.000 as possible. Higher figures translate to longer performance dips after files have been moved or deleted.

trim-2.png

This is another result sourced from a different segment of data. While our suite runs, it issues a full drive TRIM several times. Some of those times it is done on an empty SSD, while other times the SSD was full. Any difference in time taken is measured and calculated, normalizing to a response time per GB TRIMmed. In short, this is how long an otherwise idle SSD would hang upon receiving a TRIM command for a 1GB file. These times are shorter than the last chart because the SSD controller does not have to juggle this TRIM with background activity and can throw all of its resources at the request.

All Samsung parts did great here, with the MX500 behaving quite poorly (Crucial is looking into this issue as it was reported to them in tandem with our review of that product).

Everything looked fine for the 860's so far, but there was a significant issue that the 860's demonstrated but was not caught by any of the charting methods above. It stemmed from the assumption that a 'clean' (previously TRIMmed) SSD would perform a subsequent TRIM nearly instantly. This had always been the case – until now:

trim-3b-2.png

The above chart contains the clean (empty) and dirty (full) TRIM times, corrected for capacity. These were the values used to calculate the deltas in the previous chart. Focusing on even or odd items, note how the clean TRIM takes significantly longer to execute than the interleaved 850 Series products. The 860's take significantly longer here – so long in fact that the 0.012 s/GB value from the 860 PRO 4TB derives from that SSD taking nearly a minute (49 seconds) to partition and quick format under Windows. This same operation also occurs during a Windows install, and that operation sitting stalled for nearly a full minute gets into the territory where a typical user may suspect the system has hung (there is no feedback during a TRIM operation, only an unresponsive system). Smaller capacities will see a proportionally shorter delay for the same operation, but it remains significant when compared against the preceding 850 Series products.

« PreviousNext »