It's a fine utility. I use it all the time! I wanted to clarify the interpretation
of the data for the original poster. I'm still holding out hope for doing an udma66
raid0 setup on my BP6 mobo... when time permits. ~:^)
a
Andre Hedrick wrote:
> Andrew, not my utility, take it up with the author.
>
> On Wed, 14 Jun 2000, Andrew Sharp wrote:
>
> > I think you're biggest problem right now is that you aren't getting useable data
> > from hdparm. According to my man page, -T is for testing throughput of the Linux
> > buffer cache, and is supposed to avoid going to the disk all together, so I'm not
> > sure why you would bother with that test. If you want to get some numbers that
> > are more representative of what kind of throughput you can expect from your disk
> > subsystem, try a more varied benchmark approach. Do some bonnie, bonnie++ and so
> > on to get more results. Remember that a lot of IDE disks are substantially
> > cheaper than SCSI because the non-interface components are cheaper as well. A
> > lot of drive makers just slapped ide66 interfaces on the same HDA assemblies that
> > were never designed to get more than 10MB/s sustained, if that. So what you may
> > be seeing is that in raid mode you are getting more realistic results vis-a-vis
> > the actual performance capabilities of the drives themselves.
> >
> > In fact, considering the tests that you are running, the results seem quite
> > predictable. The -T mode is basically limited by the processing speed of the
> > kernel and the underlying memory architecture. So the speeds get slower the more
> > disks you add to the raid, because more CPU time is spent calculating raid
> > schtuff. I don't know how a raid0 device with just one disk works exactly, but
> > do you list results for such a beast.
> >
> > I think you'll find the results more satisfying (ie., better for 4 drives than
> > for two) if you run a test that actually does a _lot_ of reading and writing to
> > the platters themselves to get results, like a bonnie.
> >
> > a
> >
> >
> > bug1 wrote:
> >
> > > Andre Hedrick wrote:
> > > >
> > > > Those are buffered and not from the disk
> > > >
> > > > use '-t'
> > > >
> > >
> > > Hi Andre,
> > >
> > > If buffered means reading from drives buffer then i thought that would
> > > be a good way to test the limits of the ide code on my system. I wasnt
> > > after practicle benchmarks, i was trying to stress my system to see
> > > where the bottlenecks are.
> > >
> > > I recently gave up trying to get >2 hpt366 channels working concurrently
> > > and got promise ultra/66 cards, my problems with hpt366 were at least
> > > partly based on load. Im running on a dual 433 celeron (bp6) with 128MB
> > > ram, contrary to many peoples opinions of the bp6 the only problems ive
> > > had were hpt366 related.
> > >
> > > >From the tests below i hope you can see that on my hardware at least
> > > there appears to be an ide performance bottleneck. The bottleneck is
> > > beyond what is achievable by one drive so it is only appearent when
> > > using software raid or lvm.
> > >
> > > With the tests below i cant get more than total read speed of 30MB/s
> > > irrespective of how many drives i read from in parallel, but by using
> > > hdparm -T simultaneously on two seperate drives i could could get
> > > 45MB/s, which would indicate an ide bottleneck of 90MB/s.
> > >
> > > I am strugling to workout good testing methods, none of them give me the
> > > result i expect... but thats what benchmarks are for right?
> > >
> > > Do you have any suggestions on how to find IDE performance bottlenecks,
> > > or am barking up the wrong tree ?
> > >
> > > It could just be me, maybe im just jinxed, but there are others in
> > > linux-raid who also have ide performance problems, and apparently scsi
> > > raid doesnt have any performance problems (is that a good motivator for
> > > you?)
> > >
> > > I appreciate your advice
> > >
> > > Glenn
> > >
> > > P.S. im not trying to be critical of your code, im just trying to
> > > working out how much performance is possible with ide raid
> > >
> > > RAID0
> > >
> > > 4-way raid0 (/dev/hde, /dev/hdg, /dev/hdi, /dev/hdk)
> > > /dev/md0:
> > > Timing buffer-cache reads: 128 MB in 1.67 seconds = 76.65 MB/sec
> > > Timing buffered disk reads: 64 MB in 2.09 seconds = 30.62 MB/sec
> > >
> > > 3-way raid0 (/dev/hde, /dev/hdg, /dev/hdi)
> > > /dev/md0:
> > > Timing buffer-cache reads: 128 MB in 1.59 seconds = 80.50 MB/sec
> > > Timing buffered disk reads: 64 MB in 2.15 seconds = 29.77 MB/sec
> > >
> > > 2-way raid0 (/dev/hde, /dev/hdg)
> > > /dev/md0:
> > > Timing buffer-cache reads: 128 MB in 1.59 seconds = 80.50 MB/sec
> > > Timing buffered disk reads: 64 MB in 1.94 seconds = 32.99 MB/sec
> > >
> > > 1-way raid0 (/dev/hde)
> > > /dev/md0:
> > > Timing buffer-cache reads: 128 MB in 1.51 seconds = 84.77 MB/sec
> > > Timing buffered disk reads: 64 MB in 3.76 seconds = 17.02 MB/sec
> > >
> > > The drives individually
> > >
> > > hdparm -Tt /dev/hde
> > > Timing buffer-cache reads: 128 MB in 1.54 seconds = 83.12 MB/sec
> > > Timing buffered disk reads: 64 MB in 2.92 seconds = 21.92 MB/sec
> > >
> > > hdparm -Tt /dev/hdg
> > > Timing buffer-cache reads: 128 MB in 1.55 seconds = 82.58 MB/sec
> > > Timing buffered disk reads: 64 MB in 2.90 seconds = 22.07 MB/sec
> > >
> > > hdparm -Tt /dev/hdi
> > > Timing buffer-cache reads: 128 MB in 1.54 seconds = 83.12 MB/sec
> > > Timing buffered disk reads: 64 MB in 3.33 seconds = 19.22 MB/sec
> > >
> > > hdparm -Tt /dev/hdk
> > > Timing buffer-cache reads: 128 MB in 1.54 seconds = 83.12 MB/sec
> > > Timing buffered disk reads: 64 MB in 3.28 seconds = 19.51 MB/sec
> > >
> > > > On Wed, 14 Jun 2000, bug1 wrote:
> > > >
> > > > > Ive been trying to overcome performance problems with software raid0,
> > > > > currently under 2.[34] a single drive has better read performance than a
> > > > > 4-way ide raid0 (striping), write performance seems to be limited to
> > > > > about 30MB/s, for me ide raid just doesnt scale well at all. Ive
> > > > > mentioned this on linux-raid mailing list and Ingo says that scsi scales
> > > > > well acording to his tests. Others on the list also noted poor ide
> > > > > performance.
> > > > >
> > > > > So... i think ide could have some performance limitations that are only
> > > > > noticable when using multiple disks.
> > > > >
> > > > > I modified hdparm to use 1280MB for Timing buffer-cache-reads to do the
> > > > > benchmark.
> > > > >
> > > > > I do hdparm -T /dev/hde i get 86MB/s then i do hdparm -T /dev/hdi i get
> > > > > 86MB/s
> > > > >
> > > > > If i do them both at the same time i get 43MB/s for each.
> > > > >
> > > > > The drives are udma66 each on there own promise udma66 pci card,
> > > > > detected and used by the kernel as udma66.
> > > > >
> > > > > Shouldnt the performance of these drives be independent of each other,
> > > > > why would one drive slow the other down ?
> > > > >
> > > > > I run it on a dual 433 celeron with 128MB ram, when i run only one
> > > > > instance of hdparm it uses 50% of cpu resources, when i run both
> > > > > concurrently combined they use 100% (aprox). So i assume hdparm isnt
> > > > > multi-thrreaded, given this i dont think cpu resource should be causing
> > > > > the bottleneck.
> > > > >
> > > > > Could this be a software (kernel) limitation rather than hardware ?
> > > > >
> > > > >
> > > > > Thanks
> > > > >
> > > > > Glenn
> > > > >
> > > > > -
> > > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > > > the body of a message to majordomo@vger.rutgers.edu
> > > > > Please read the FAQ at http://www.tux.org/lkml/
> > > > >
> > > >
> > > > Andre Hedrick
> > > > The Linux ATA/IDE guy
> > >
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to majordomo@vger.rutgers.edu
> > > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> Andre Hedrick
> The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:33 EST