Software RAID vs. Hardware RAID: Behind the Scenes
One of the first questions we felt needed to be answered was what exactly hardware RAID cards do.
Although we knew that hardware RAID cards perform the parity bit calculations on the card itself, some debate surrounded over where other RAID calculations occur. Some thought that it was only the XOR calculations that occur on the coprocessor and that other calculations are passed to the CPU just as in software RAID. Others thought the opposite: that the hardware RAID's coprocessor performed all RAID functions including the division of files into stripes and deciding what information to send to what drive.
Since we knew that if RAID functions (other than XOR calculations) were performed on the CPU, CPU utilization would be higher than if the CPU did not have to do these task, we thought that measuring CPU utilization would give us a good indication of whether or not hardware RAID cards require the CPU at all. The problem was that during our testing the amount of CPU power required to perform the RAID tasks on even the software RAID cards was minimal, as we will soon see.
Therefore, we decided it would be best to stress the CPU in an effort to make the task of performing RAID calculations more difficult. To do this, we installed FlasK MPEG and set it to encode a MPEG2 movie that we had into MPEG4 (or Divix) file. At the same time, we ran a single Iometer run in the workstation access pattern under the medium I/O load (to add even more stress to the environment). For our software RAID card we used the Promise FastTrak100 in a RAID 0 configuration, and for the hardware RAID card we used its brother, the Promise SuperTrak100, in the same configuration. The results allowed us to gain insight on what was going on behind the hardware RAID configurations.
The above graph clearly shows that the CPU has to do drastically less work when RAID functions are performed on a hardware RAID card. Since in the above RAID 0 configuration no XOR calculations are occurring, the work offloaded from the CPU onto the hardware Raid's coprocessor must be the basic RAID functions such as the striping of the data.
So, the hardware on RAID cards do more than just the calculation of parity bits. It seems that the coprocessor eases the burden of software RAID when the CPU is put under extreme stress. More on how well this works in a bit, but now it is time to get to the nitty gritty of the tests: individual card performance.
Facebook
Twitter
RSS
2 Comments
View All Comments
kburrows - Thursday, December 4, 2003 - link
Have you run any tests on any onboard RAID solutions for RAID 0 & 1? I would love to see the results posted for the new SATA RAID on the Intel 875 boards.Anonymous User - Sunday, August 17, 2003 - link
In adressing the performance of an raid array with different stripe sizes, you miss an important factor, namely the accestime of an disk. This wait time has two main couses. First the head positioning and second the rotational latency (the heads track the right trace, but position where the read start has not passed under the head). You may have to wait from 0 to (in the worst case) a full cycle.Since the disks move independently You can calculate that the average latency to get an small file is minimal when the stripe size is about an full cycle of an disk in the array (aprox. 250kB today). All other factors I do know do not reduce this. (controller overhead, transport,...)
So I think that today a minimum stripe size of 256kB should be used.