[1471] in linux-scsi channel archive
Re: Disk array latency theory (was: EATA performance issues)
daemon@ATHENA.MIT.EDU (Dario_Ballabio@milano.europe.dg.co)
Wed Feb 26 03:20:26 1997
Date: Wed, 26 Feb 1997 09:17:35 +0100
From: Dario_Ballabio@milano.europe.dg.com
To: linux-raid@vger.rutgers.edu, linux-scsi@vger.rutgers.edu,
lma@varesearch.com
%UATTACH
> Cc: mike@i-Connect.Net
> In-Reply-To: <199702250827.JAA19306@milano.europe.dg.com>
> \011(Dario_Ballabio@milano.europe.dg.com)
> I exchanged email with Mike Neuffer and he suggested I try 1) dividing
> the disks between the two SCSI busses on the controller, and 2)
> creating the RAID-5 drive by alternating disks from SCSI busses when
> adding drives.
>
> I also tried rev. 3.00.00 of the EATA driver.
>
> Neither of these had any significant affect on performance.
>
> I'll append my latest set of benchmarks.
>
> Has anyone else reported performance numbers for RAID configurations
> on this controller? I'd like to compare my numbers to other people's
> numbers.
>
> Larry
>
> Iozone Size Rec Length Read Rate Write Rate
> Directory Mbytes bytes Kbytes/sec Kbytes/sec
> /u1 244 512 5785.04 2007.52
> /u1 244 512 4896.26 2061.86
> /u1 244 512 4961.40 2096.99
> /u1 244 512 6158.64 1849.28
> Average 244 512 5450.33 2003.91
>
RAID5 is not aimed to sequential performance, it is good for OLTP
systems where there are sereval simoultaneous, independant, small,
random operations. Your numbers are the very best that you can expect
from any RAID5 implementation. Try to benchmark RAID5 using the above
load pattern agains single disks and you'll see the benefits.
Moreover you should always expect that RAID5 writes are 2.5 - 3 times
slower than reads on sequential operations. This problem can be
solved by a good write cache implementation, but only for the
load pattern suitable for a RAID5 array. If you are interested
in sequential performance you shold use RAID3 or RAID0, but the
unavoidable disk latency on arrays (when disks are non in phase)
reduces the benefits by a factor.
It is also normal that you do not get any benefit from the elevator
sorting feature in the EATA driver rev. 3.00 for sequential operations:
the average seek distance is very low and requests are already sorted
at the source. To see some benefit you could try something like this:
date
for i in 1 2 3 4 5 6 7 8 9 10
do
dd if=/dev/sdc of=/dev/null bs=128b &
dd if=/dev/sdd of=/dev/null bs=128b &
dd if=/dev/sde of=/dev/null bs=128b &
sleep 30
done
wait
date
Cheers,
db
