Re: Absolutely horrid IDE performance...

Gerard Roudier (groudier@club-internet.fr)
Sat, 5 Dec 1998 10:01:38 +0100 (MET)


On Sat, 5 Dec 1998, Mark Lord wrote:

> Gerard Roudier wrote:
> >
> > On Wed, 2 Dec 1998, Mark Lord wrote:
> >
> > > > -------Sequential Output-------- ---Sequential Input-- --Random--
> > > > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
> > > >Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec
> > > >%CPU
> > > > 256 17374 95.5 32681 33.2 10706 24.3 15683 68.4 23710 24.3 214.6 1.8
> >
> > Just my comments on this benchmark results:
> >
> > 1) Block write = 32681 KB/second
> > Comment: Not relevant, if as I guess the machine has probably 128 MB
> > memory.
>
> Yes, but the same results are achievable on less.
> The test file was 256MB. Those are *real* throughput rates,
> not buffer-cache buggered speeds.

Due to the way Linux caches blocks, you must use far more than the main
memory size for the bonnie file size there if you want relevant results.
You may want to less us know the results using a 512 MB file for
example.

And if your pair of drives together are really able of 32 MB sustained
data rate, why is the block read result so less than this number (23
MB/s).
I doubt they are but if they do, then 32 MB write against 23 MB read would
mean that prefetching (from the drive cache and for the kernel) is
really behaving bad with these IDE disks.

How much cache have your disks? Since your disks aren't synchronized, the
software raid0 may requires the drive to perform more than 1 track
buffering in order to be able to get additive sustained data rate with
raid0.

> > 2) Block read 23710 KB/second against Character Read 15683 KB/s
> > and only 68.4 % CPU.
> > Comment: You should get at least 90 %. Something is behaving not well
> > somewhere.
>
> Why should it get 90%? The machine is very fast, and has to wait
> sometimes for I/O. Again, no bogosity there.

Extremally broken data prefetching there in my opinion.

> > For your information, here is a benchmark result with Linux 2.1.30 and the
> > stock driver I got a couple of days ago using a single Cheatah2.
> > (PII 233 / 66MHz SDRAM + 64MB + SYM53C895)
> >
> > -------Sequential Output-------- ---Sequential Input-- --Random--
> > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
> > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
> > 4K ext2 300 10656 97.7 19235 23.7 8346 26.5 13097 91.8 18602 21.0 229.2 4.7
>
> Looks pretty wimpy, even by IDE standards.

1) The Cheatah2 sustain data rate is about 18-19 MB/s and we are able to
get this speed with both read and write.
2) Using character read and write we are able to use almost 100% CPU load.
3) CPU load is nicely low for the system used for this benchmark.

If you aren't able to get such qualitative results (1+2+3) with a disk IO
subsystem, then that means that something behaves badly in this subsystem.

Regards,
Gerard.

-
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/