Single page Print

IOMeter — Sequential and random performance
IOMeter fuels much of our latest storage test suite, including our sequential and random I/O tests. These tests are run across the full capacity of the drive at two queue depths. The QD1 tests simulate a single thread, while the QD4 results emulate a more demanding desktop workload. For perspective, 87% of the requests in our old DriveBench 2.0 trace of real-world desktop activity have a queue depth of four or less. Clicking the buttons below the graphs switches between results charted at the different queue depths.

Our sequential tests use a relatively large 128KB block size.

The SU800's sequential read speeds are superb, matching the fastest SATA SSDs and offering a modest increase over the MX300's reads. Its write numbers trail even the notoriously pokey Crucial BX200, however. We brought up our numbers with Adata before publication, and the company replicated our test setup and confirmed that our results are no anomaly. The official explanation is that the drive's SLC-cache has not recovered in between IOMeter filling the drive with its test file and actually executing our scripted benchmarks. We've seen similar problems with other drives before, but none have yielded such a troublesome end result.

The 28 MB/s figure we're seeing is essentially the TLC NAND's true write speed when caching tricks aren't in play. It's not entirely clear why some drives are able to flush their caches enough to be able to operate at acceptable speeds while others have such a terrible time of it, but we can hazard some guesses. One of the features of the SM2258 is a "direct-to-TLC algorithm," which enables the controller to bypass the SLC buffer when it's saturated and shuttle incoming writes directly to the drive's TLC. It's possible that our IOMeter setup has exposed an unusual behavior in the controller's programming regarding when to use or skip the SLC cache mode.

Without another SM2258 drive on hand to compare against, it's hard to know whether to point the finger at Adata or Silicon Motion here. But results are results, so the SU800 will have to work hard to make up for that 28 MB/s black mark throughout the rest of our testing suite.

For better or for worse, the drive's random response times aren't particularly exciting. Read responses are a bit quicker than the MX300's were, but write responses are substantially slower. Let's move on to some more interesting tests.