[NTLUG:Discuss] Disk performance.

Dan Carlson dmcarlsn at yahoo.com
Wed Dec 13 15:17:38 CST 2000


On my Celeron 500 MHz system using Linux's software RAID support I get the
following:

16.84 MB/sec on a two drive RAID 1 array on two 7200 rpm drives UDMA 66
drives running as UDMA 33.

18.55 MB/sec on a four drive RAID 5 array on two 5400 rpm UDMA 33 drives and
two 7200 rpm UDMA 66 drives running as UDMA 33.

These numbers are obtained using hdparm -t on the md RAID partitions.

Hdparm is a simplistic and synthetic benchmark that is not representative of
realworld performance.  In addition to hdparm you might try using bonnie.
It is supposed to be more realworld than hdparm, but I can't speak from
experience since I've never used it.  The main difference is that hdparm is
accessing the md device directly, without any filesystem overhead.   Bonnie
goes through the filesystem, so it certainly should be more realistic.

My guess is that with a fast CPU, fast IDE drives running as either RAID 1
or RAID 5 arrays, and the right UDMA IDE controllers, you should be able to
exceed 20 MB/sec for long sequential reads.  For short random reads and for
writes the performance will be lower.

Unless you get lucky, you can expect to have to use trial and error to find
the best (i.e. highest performance under Linux) combination of IDE drives
and UDMA controllers.  I had had good luck (i.e. no real problems) getting
the Promise UDMA/66 controller to work with Mandrake 7.1 (it basically works
"out of the box").  However, my nice 7200 UDMA 66 drives won't run UDMA 66
with the Promise under Linux, they only run as UDMA 33.  From what I've
read, this is typical.

UDMA 100 drives and controllers are now available, but I don't have any
experience with them.  One thing to watch out for is that you are buying a
drive that can actually deliver data at the interface rate; many drives
cannot.  For example, many UDMA 66 drives only deliver data to the interface
at ~40-45 Mbits/sec, so having the interface run at 66 doesn't buy you as
much as it first appears.  I expect that this is probably more prevalent
with UDMA 100 drives than it was with UDMA 66 drives.  The drive
manufacturer's spec sheets usually include the rate at which the drive is
capable of delivering data to the interface.

Have fun, and keep us posted on the results.

Dan Carlson

----- Original Message -----
From: "Steve Baker" <sjbaker1 at airmail.net>
To: "NTLUG DISCUSS" <discuss at ntlug.org>
Sent: Wednesday, December 13, 2000 3:30 PM
Subject: [NTLUG:Discuss] Disk performance.


>
> Does anybody here have much experience of measuring disk drive throughput
> rates?   It's an area of PC computing that I know very little about.
>
> I have an application that needs to load large (multi-megabyte) files very
> quickly from disk for long, sustained periods.  The nature of what I'm
doing
> means that caching data in RAM won't help because I don't read the same
> file twice (well, not until we've loaded many, many Gigabytes of other
stuff
> along the way).
>
> On my PC here at home (which has a 450MHz CPU and a vanilla low-end 20Gb
> IDE drive) I'm managing to load about 5Mbytes/sec. (These files are 'PNG'
> images - and they have to be uncompressed on-the-fly).
>
> My question is - if I go out and pick a good disk drive - or several
> drives - SCSI or IDE or whatever else works - or perhaps a RAID array
> or something - slap in a 1GHz CPU on a good motherboard...what kind of
> speedup would you expect I would get?
>
> I'm hoping to get at least 20Mbytes/sec - more would be good.
>
> --
> Steve Baker   HomeEmail: <sjbaker1 at airmail.net>
>               WorkEmail: <sjbaker at link.com>
>               HomePage : http://web2.airmail.net/sjbaker1
>               Projects : http://plib.sourceforge.net
>                          http://tuxaqfh.sourceforge.net
>                          http://tuxkart.sourceforge.net
>                          http://prettypoly.sourceforge.net
>
> _______________________________________________
> http://ntlug.org/mailman/listinfo/discuss
>




More information about the Discuss mailing list