ADATA Premier SP610 SSD (256GB & 512GB) Review: Say Hello to an SMI Controller

AnandTech Storage Bench 2013

Our Storage Bench 2013 focuses on worst-case multitasking and IO consistency. Similar to our earlier Storage Benches, the test is still application trace based - we record all IO requests made to a test system and play them back on the drive we are testing and run statistical analysis on the drive's responses. There are 49.8 million IO operations in total with 1583.0GB of reads and 875.6GB of writes. I'm not including the full description of the test for better readability, so make sure to read our Storage Bench 2013 introduction for the full details.

We are reporting two primary metrics with the Destroyer: average data rate in MB/s and average service time in microseconds. The former gives you an idea of the throughput of the drive during the time that it was running the test workload. This can be a very good indication of overall performance. What average data rate doesn't do a good job of is taking into account response time of very bursty (read: high queue depth) IO. By reporting average service time we heavily weigh latency for queued IOs. You'll note that this is a metric we have been reporting in our enterprise benchmarks for a while now. With the client tests maturing, the time was right for a little convergence.

Well, this doesn't make much sense. The service times aren't anything special, yet the average data rate is surprisingly high. For instance the 256GB JMF667H drive has lower service time but the average data rate is lower.

For this to make some sense, let's look at the service times for reads and writes separately.

Now this makes more sense. Due to the relatively poor IO consistency of the SP610, the write service times are quite high. That increases the average service time substantially but the impact on average data rate is smaller, and the reason for that is quite simple.

To keep thing simple, imagine that it takes five seconds to write 128KB of sequential data and one second to write 4KB of random data. In other words, it takes six seconds to write 132KB of data, which works out to be 22KB/s. However, the 128KB write operation completed at 25.6KB/s, whereas the throughput of the 4KB write operation was only 4KB/s. 22KB/s is certainly much closer to 25.6KB/s than 4KB/s, meaning that the average data rate gives more emphasis to the large transfer because frankly it counts more when looking at amount of data that was transferred.

But now add in the service time. It took a total of six seconds to complete two IOs, which means that the average service time is three seconds. It doesn't matter that the other IO is much larger because service time only looks at the completion time of an IO, regardless of its size. Because of that, the service times give more information about small IO performance than the average data rate where the small IOs are buried under the larger transfers.

In the context of the SP610, this means that it performs well with large IOs as the data rate is high. Only about 30% of the IOs in the trace are 4KB, whereas 40% are 64KB and 20% are 128KB. With small IOs the performance is not bad but for instance the JMF667H does slightly better, resulting in lower service times. Despite the mediocre performance consistency on the previous page, overall the SP610 does very well in the 2013 Storage Bench and potentially offers users better performance than the MX100, 840 EVO and JMF667H.