Performance: Promise FastTrak100
As the card section coves, this Promise FastTrak100 card is based on the Promise PDC20267 software RAID controller. Lets see how the card did.
As we saw before, the Promise FastTrak100 offered a variety of stripe sizes. The above graph shows that the performance of the card seems to peak around the 64KB to 128KB stripe range when it comes to how many I/Os per second the card can perform. As the stripe sizes get larger than these, the performance of the card seems to level off.
We see the same trend when looking at the MBs per second speed of the Promise FastTrak100. Here the maximum speeds reached occur around the 64KB to 128KB stripe range, after which speed levels off. For the raw numbers involved, please see the end of this section.
This time we see a mirror image of the previous results since in the measure of I/O response time lower is better. The minimum response times in all access patterns lied in the 64KB to 128KB stripe size range, with the performance leveling off after this.
As we saw in the AMI software RAID card testing, CPU usage varies greatly so we are really only able to report on trends we see in the graphs. Above we can clearly see that the smaller stripe sizes use much more CPU time than the larger ones. This is due to all the division work the CPU has to do when the stripe size is small. The trend is for the CPU utilization to decrease until the 128KB stripe size and then slightly increase again.
Once again it seems that the synthetic numbers outputted by Iometer equate to real world performance. In this case, the optimal stripe size appears to be 64KB, as this is where Content Creation Winstone 2001 was able to perform the best.
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.