Multithreaded Read & Write Patterns
The multithreaded tests simulate a situation when there are one to four clients accessing the disk at the same time – the clients’ address zones do not overlap. We will discuss diagrams for a request queue of 1 as the most illustrative ones. When the queue is 2 or more requests long, the speed doesn’t depend much on the number of simultaneously running applications. You can also click the following links for the full results:
The multithreaded load produces interesting results. With no read request queue, we see that the real speeds of the SSDs (we will also see them shortly in FC-Test below) are very far from their maximum ones. Why? Because they are just not loaded heavily enough to show their very best. In our sequential read test the SSDs were nearly as fast as specified at a queue depth of 4 requests, but here, with no queue at all (and that’s the scenario we have when a single user is accessing a single file), we see them deliver only one third or one fourth of their maximum. The funny consequence is that first place goes to the outsider of this test, our custom-made JBOD sample.
But when there are two data threads, the SSDs can read them in parallel and double the speed. The only model that doesn’t speed up is the same JBOD-based sample.
When reading four data threads, the IBIS series go ahead. Even the IBIS model with the fewest number of memory chips proves to be faster than the highest-capacity model with two flash controllers.
We’ve got a different picture at multithreaded writing. There are no performance hits when the number of data threads increases, yet there is no performance growth, either. So, the SSDs do not seem to find this load too easy. It is the capacity rather than the number of memory channels that becomes the crucial factor here. This is indicated by the quad-controller 100GB products being outperformed by the 240GB RevoDrive.