Multithreaded Read & Write Patterns
The multithreaded tests simulate a situation when there are one to four clients accessing the virtual disk at the same time, the request queue depth varying from 1 to 8. The clients’ address zones do not overlap. We’ll 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 applications.
The drives’ read speeds have been limited by the interface bandwidth in every case, save for the eSATA interface, so it is normal that the slow interfaces do not get worse under multithreaded load while the XTreme with eSATA slows down by 50%. Anyway, the latter drive is still the fastest of all.
And there are more odd results at writing. The USB interface is in the lead at one thread while the theoretically faster eSATA and FireWire are very slow. The latter’s speed of 3.66MBps looks like a bad joke. Is it writing data in 512-byte blocks and thinking long over each block?
The situation improves when there are more write threads because the USB implementations slow down while the FireWire and eSATA interfaces accelerate. The eSATA drive’s result with four threads is impressive: it proves to be able to write at full speed!
And if you click the link above and take a look at the table, you will notice a couple of funny things more. It turns out that the FireWire cannot stand a queue depth of 8 requests, slowing down to 3.6MBps. The success of the eSATA interface with two and three threads only refers to a queue depth of 1 request (i.e. with no queue at all). Otherwise its speed plummets to 7MBps. But when there are four write threads, its speed grows up along with the queue depth.
These results are hard to explain, really.