Latency Percentile and TurboWrite Cache Testing

Latency Percentile

For this article, I'm going to put a bit of a twist on our Latency Distribution and Latency Percentile testing. In order to better approximate actual consumer usage, I will be intentionally pacing the test at a 50% duty cycle. This should give us random write results closer to what typical users will actually see, and the majority of the latency results should result from writes to the SLC area of these caching SLC/TLC hybrid solutions.

distribution.png

The four results include a first pair, in which the 120GB and 250GB 750 EVO saw a 100 second continuous 4k random run at QD=4. The second two results are of the same pair of SSDs seeing the exact same workload, but at a 50% duty cycle. This means the workload ceased every two seconds, giving the SSD two seconds of idle time between pulses.

It's interesting to note that in both cases, all capacities of the 750 EVO perform in an extremely tight latency band at QD=4. I had originally expected the 50% duty cycle to yield more of a different result, but as it turns out, QD=4 was not high enough to saturate the TurboWrite buffer over the 100 second continuous test run, making the results for both test cases nearly identical. We did note an additional cluster of ~100 total IOs falling at the ~100 microsecond mark in the intermittent run, but that can easily be explained as the first IO of each two second burst, which saw the 750 coming out of what was previously an idle state (where it was likely emptying its SLC buffer into TLC). To demonstrate just how tight the latencies are here, take a look at the percentiles:

percentile.png

Such a tight band across two different conditions and two different capacities is mighty impressive. To give this some additional perspective, lets add some preliminary results from a pair of other competing low cost SSDs into the mix:

percentile-2.png

What we see here are a few things (after noting that I had to increase the range on the chart by another 10x to include the slower results). First, the OCZ Trion SSDs both run out of cache at different percentages of the 100 second run (~22% for the Trion 100 and ~73% for the Trion 150). We also see that the SLC latency of the Trion SSDs is much greater (~47 us) than the 750 EVO (~27 us, or 1.7x faster response per IO). These latencies taper off to far greater figures as the Trion Series products fill their cache and transition to TLC writing. Once this happens, the performance gap increases to a range of 5x – 13x for that fraction of writes going to TLC on the Trions. Note from the legend that IOPS are similar across all of the models / situations tested, but the latency of those IOs is what really dictates how SSDs 'feel' in actual use.

As you can see, with proper context, the previously boring and tightly packed 750 EVO results can show a bit more perspective on just how good they actually are.

Cache Testing

Now lets wrap this up with a quick check on sequential copies to the 750 EVO from a fast source:

120GB:

samsung-750-23.png

250GB:

samsung-750-22.png

Apologies for the overlapping window inadvertently captured in that last one. The test file here was ~4GB, and we can see the obvious drop from SLC speed down to TLC speed, which takes place at the 3GB mark at both capacities. That slower sustained write speed comes out to 133 MB/s and 211 MB/s when tested within Windows (note: the Windows write cache is disabled for this test, so sustained speeds are a tad higher in real use). These are a bit shy of the original sustained ratings of the 850 EVO, but we suspect some additional care is being taken during writes as a means to correct the slow down issue originally present in the 840 EVO.

« PreviousNext »