Performance in Intel IOMeter DataBase Pattern
This pattern serves to check out the controller’s ability to process a mixed stream of read/write requests with random-address 8KB data blocks. By changing the ratio of reads/writes we can see how well the driver sorts out the mixed stream of requests.
The table is unusually large, and I gave up the idea of painting it up (it was a horrible multi-colored picture). Let’s do this in diagrams. First, let’s see how the controllers behave under the linear workload (request queue depth = 1).
All controllers start out with similar results, but as the writes share increases, we see two controllers – the VIA and the Promise in the WT mode – getting to the top. We know them from the Sequential Read pattern, they just rank up otherwise here. The same Promise in the WB mode joins them by the end of the diagram (100% writes).
Note that the integrated controller from VIA is the best at doing deferred writes! Is it going to be the favorite of our today’s tests?
We increase the workload to 16 outgoing requests to see the following:
The VIA controller got a bit faster, but anyway lost to the others! Promise in the WT mode sped up more than everyone else. The VIA controller approaches the leaders when there are more write operations.
Now we increase the workload to the maximum of 256 outgoing requests:
There is no definite leader, but the VIA controller fell far back at reading. When there are more read requests, the integrated controller from Intel seems preferable, while the controller from Promise in the WT mode is better than the others when the writes share is higher.
Now let’s check the performance of our testing participants in the patterns that emulate the disk subsystem workload of a typical server.