Andre M. Hedrick wrote:
>I get 12-13 rates with UDMA chipset amd UDMA Drive..........
>My oldest UDMA drive is a brick at 8.7 a Quantum FB 3.2 ST
>Next oldest UDMA drive is better at 9.8, a Quantum FB 6.4 ST
>Here is the drive is better at 10.92, a Quantum FB 8.4 SE
>The newest pair of drives are at 12.38, are Maxtor 6.8
>
>As you see it is the drive.........all of these numbers are on the same
>chipset.........the Quantum FB ST's are from memory.
Hmm. Assuming those are hdparm numbers and not e.g. bonnie:
On my ASUS P5A with Ali 5 chipset, a Quantum EL 5.1
(and K6-2-300, 128Mb PC100 SDRAM), with hdparm 3.5 on Linux
2.1.126 and later, I get something like:
$ hdparm -tT /dev/hda
bla-bla 128Mb: 51 Mb/s
bla-bla 64Mb : 11.19 Mb/s
It's using PIO 4 (as linux doesn't currently support
UDMA/DMA on my Ali chipset) and multcount is set to 8,
io to 32 bits.
Is this drive actually doing 11 Mb/s in PIO (not that
I mind)?
Does this mean I'm using (roughly, at least, on
average) 11.19/16.66 ~= 2/3 of the CPU's processing
power PIO-ing things off the drive (in e.g. a long
running "just read and do nothing with the read data"
test)? If true, the above suggests that neither the
CPU nor the 16.66 Mb/s interface is a bottleneck (in
the hdparm test), as this leaves about 1/3 of the CPU
power for linux'
housekeeping/context-switching/whatnot and hdparm,
which I'm guessing would do. Or could I still expect a
(significant) increase in
_hdparm_measured_throughput_ when using UDMA/DMA
(i.e., ignoring the effect the lower CPU load
would/might have on a real app)?
Regs,
Alex.
PS. Andre: Please consider the pain and suffering you
are causing by mentioning that ide-update-13 is
expected "soon", and it still not appearing on your
site days later ;)
--- 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/