There are quite a few variables that can affect speed, but here's some basic ideas to get a feel for what a given raid set should be capable of.
Raw disk throughput
Assuming that a random seek completes an average of 1/2 of a rotation (180 degrees) away from the sector you want, the average random access time is one average seek plus the time the disk takes to rotate 180 degrees.
On a 10K RPM disk 1/2 of a rotation
takes approximately 3ms.
On a 15K RPM
disk 1/2 of a rotation takes
Average seek time for a Seagate
Cheetah 15K6 is quoted at 3.5ms for
reads and 3.9ms for writes (I presume
the writes include a period to align
the head on the servo tracks). A 10K disk is slightly longer.
So, a raw estimate is an average of
5.5ms per random seek for a 15K drive and 7ms for a 10K drive. Tagged
command queuing will optimise this
slightly. Thus, for a 15k drive we
have a theoretical random throughput
of about 180 IOPS and 140 IOPS for a
On a non-striped RAID-1, reads can be split between the two disks, but writes must go to both drives. Random operations will give you twice the throughput of a single disk for reads and approximately the throughput of a single disk for writes. Sequential I/O tends to peak at the maximum throughput of a single disk. Interface cables may or may not present a bottleneck.
Striped RAID sets
RAID-5, RAID-10 or RAID-50 disks have the data split up into chunks spread in a round-robin fashion amongst the members of the RAID set. Assuming no read-ahead optimisation a disk can read at most one stripe per revolution of the disk. A 10K disk revolves about 170 times per second and a 15K disk revolves about 250 times per second.
For a 64K stripe this comes to
approximately 10MB/sec per 10K disk or
15MB/sec per 15K disk. Larger stripe
sizes give you better sequential
throughput on the disks - for example
a 256K stripe size on an array of 15K
disks would give you 60MB/sec per
disk. A heavily random access
workload will reduce this by
introducing more latency between
seeks. Read-ahead on a controller
might increase it.
Thus, an array with 14 15K disks using 64K stripes would have a theoretical streaming throughput of around 210MB/sec assuming no other constraints. If the controller is not fast enough the practical rate may be lower (for example, I could never get a dell PV660 to get more than one read per two revolutions of the disks). A heavily random access workload would also be somewhat slower because the disk accesses will average less than one per revolution of the disk. Some reads will also be used on parity data so the actual application data throughput would be a bit slower.
The fastest possible write on a RAID-5 involves two reads and two writes. The controller has to read the old block and corresponding parity block, XOR the old and new data with the parity block to recalculate the parity and write out the new block and parity. Caching can reduce the amount of disk activity if the old block and parity block are in cache. The same applies to a RAID-50.
A RAID-10 needs two disk accesses per write - one to the main and the other to the mirror. Read performance is roughly equivalent to a RAID-5.
In some cases (fibre channel is prone to this) the connections to the physical disk subsystem are of somewhat lower bandwidth than the disks are theoretically capable of delivering. Also, disk controllers can perform poorly. In many cases this is a more significant limitation than the disks themselves. High-end SAN hardware often has large multiprocessor machines as controllers - they may also have custom hardware for fast parity calculations. The controller for an EMC DMX takes up half a rack by itself - before you put any disks on it.
Tuning the disk itself
Caching and read-ahead parameters on the disks themselves may also affect performace for certain workloads. For example, disks using Seagate's 'V' firmware might be set up for fewer larger cache segments and agressive read-ahead to optimise for streaming throughput of media data. The same physical disk configured for use in a Clariion would be configured with more, smaller cache segments in order to support a larger number of smaller writes from many clients on a SAN.