Linux-kernel mailing list archive 1998-31,: Re: IDE drive data transfer rates, kernel optimization?

# Re: IDE drive data transfer rates, kernel optimization?

Joel Jaeggli (joelja@darkwing.uoregon.edu)
Wed, 5 Aug 1998 14:00:52 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: LLORNKCOR: "Re: multiple messages"
- Previous message: Meelis Roos: "Re: IDE drive data transfer rates, kernel optimization?"

<trimmmed for brevity>

Mike A. Harris mharris@ican.net wrote:

>
> Some other interesting things... the pdf datasheet says that the
> drive has an internal data transfer rate (disk to buffer) of
> 158Mb/s. Other parts of the sheet refer to MEGABYTE as MB, so
> I'm assuming that Mb means megabit which makes more sense than
> does Megabyte for the number "158". So at 158 megabits per
> second data transfer from disk to buffer, we get:

No the internal transfer rate is measured in megabytes per second.
> 158 / 8 = 19.75MB/s or 19 megabytes per second.
>
> This is NOT the rated 33megs per second that the sheet claims for
> UDMA operation. The rate for PIO/DMA is 16.6Mb/s. I get 7.8Mb/s
> or roughly half of spec. Does this mean that if I use UDMA, I
> can expect around double, or 15Mb/s? If so, that is far from
> 33Mb/s, and still not quite even the calculated 19.75Mb/s that
> the internal buffer supports.

No. you'll probably see >11-12MB a second on the current generation of
5400rpm ide disks.
> What gives with these specs? What is even more confusing is that
> at the bottom of the document it says "Quantum defines a megabyte
> as 1000000 bytes". That adds a hell of a lot of confusion to
> their datasheets, and accepted standards. I realize that Quantum
> is not the only drive manufacturer doing this however - they all
> do it.

They do this primarily to inflate the size of their disks.
> Question: How can one tell what the true speed will be for a
> given drive from a given manufacturer? Is there a formula? My
> formula is currently: rated-internal-buffer-rate/8 * 0.40

There is no formula. Theoretical limits based on assumptions of rotational
speed, head performance, cache perfromance and various signaling rates are
always going to be radically higher than the actual performance of a
drive. With a decent scsi controller and a bunch of drives performance can
begin to approach the media speed, but not with an individual disk (short
of something like a quantum rushmore ssd (which is not technically a
disk)) and not with ide, given only two disk per channel and one operation
at a time.

> Is this accurate?
>
> At any rate, my kernel related question on this topic is, aside
> from the current support in the kernel, what new efforts are
> underway to get the most out of a hard disk? Does one need to go
> with a RAID array to get 33Mb/s?

Each ide channel can still only handle one operation at a time. given
that, using the multidisk driver will provide incrementally (but not
majorly) higher performance. Hardware raid controllers for ide do exist, I
am not ware of any projects working on drivers for them (although they may
exist).
> Can anyone shed light on getting more speed out of these drives?
> I'm currently using:

The kind of performance you're seeing is actually quite reasonable, if not
exceptional for a udma ide disk. A while back I ran iozone on a whole pile
of disks. The results of which you can see at:

http://limestone.uoregon.edu/beowulf/disk-benchmark.html

I should really run all the tests again with bonnie against a larger
number of disk but I've been busy.

> /dev/hda:
> multcount = 16 (on)
> I/O support = 1 (32-bit)
> unmaskirq = 0 (off)
> using_dma = 0 (off)
> keepsettings = 0 (off)
> nowerr = 0 (off)
> readonly = 0 (off)
> readahead = 8 (on)
> geometry = 524/255/63, sectors = 8418816, start = 0
>
>
> Now back to your regularly scheduled programming. (pun intended)
>
>
>
> --
> Mike A. Harris - Computer Consultant - Linux advocate
>
> Escape from the confines of Microsoft's operating systems and push your
> PC to it's limits with LINUX - a real OS. http://www.redhat.com
>
>
>
> -
> 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.altern.org/andrebalsa/doc/lkml-faq.html
>

--------------------------------------------------------------------------
Joel Jaeggli joelja@darkwing.uoregon.edu
Academic User Services consult@gladstone.uoregon.edu
PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--------------------------------------------------------------------------
It is clear that the arm of criticism cannot replace the criticism of
arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.

-
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.altern.org/andrebalsa/doc/lkml-faq.html

- Next message: LLORNKCOR: "Re: multiple messages"
- Previous message: Meelis Roos: "Re: IDE drive data transfer rates, kernel optimization?"