Performance in Intel IOMeter Sequential Read & Write Patterns
The array receives a stream of read/write requests with a request queue depth of 4. Every minute the data block size changes, so we get a dependence of the linear read/write speed on the data block size.
HighPoint RR1520 failed in the Sequential Read test – its speed hits against a mysterious ceiling of “31MB/s”. It’s like the good old times of ATA/33 returned!
Promise with the WB configuration and the VIA controller are leaders on small blocks, while the same Promise with the WT configuration was slower than the rest of the controllers on blocks 4KB-64KB big. Other controllers form up a dense group.
All controllers show the same speed of 100MB/s on big data blocks, save for the loser from HighPoint.
The excellent performance of the VIA controller came as a surprise so we checked out one supposition. As you remember, the high read speed of the Promise controller is achieved by pre-processing of the requests. If the driver “sees” that the array receives sequential requests, it “glues” them up together, producing a higher data-transfer rate. So it was quite logical to suppose that the similar performance of the VIA controller is achieved due to the same requests processing mechanisms. But in this case the CPU workload should be above the average anyway!
Our supposition was confirmed as the VIA controller produced a CPU workload of 77% when processing 512-byte data blocks, while other controllers, save for the Promise (WB), loaded the CPU by about 50% on the same blocks. So, as usual, every performance gain comes at a certain price.
Let’s now turn to writing:
Promise controller in the WB mode wins the write test (thanks to the driver’s ability to “enlarge” the write request). The integrated controller from Intel jumped above the rest of the controllers on 8KB blocks. It is very curious fact, I should say.
The controller from HighPoint performed like any other at first, but soon fell hopelessly behind. On the other hand, it is definitely better at writing than at reading!
It is funny, but the LSI controller couldn’t keep up the tempo on the 2KB-32KB stretch. I guess the driver is the one to blame here, since other two controllers on the Silicon Image chip showed higher speed.