On Mon, Aug 22, 2005 at 09:33:40AM +0100, Dieter wrote:
> > Please try the attached test program:
> > ./tst /dev/rwd0c 10000
> > 
> > this will report the speed of the bus (data transfers between the disk's
> > cache and main memory). Maybe you're hitting the limit of what the hardware
> > can do here.
> 
> I added 3 lines to get rid of some compiler warnings:

Thanks, I fixed my source.

> 
> I ran it a few times, the fastest result on a mostly idle system:
> 
> 17471975 us, 35.771571 MB/s
> 
> Again, results are about the same at the beginning and the end
> of the drive.
> 
> I/O on a SCSI drive at the same time drops the speed slightly,
> to about 33 MB/s, perhaps due to PCI bus contention.

Yes, or because the interrupt delay is sightly increased.

> 
> I/O on the other SATA drive on the same controller drops the
> speed significantly, to 19-20 MB/s per drive.
> 
> It looks to me like the Sil 3512 controller is maxing out.

Yes, that looks like the problem.

> 
> Another result that appears a bit odd, is that running
> 
> 	dd | hexdump -C
> 
> reduces the throughput from 36 MB/s to 13 MB/s.  The CPU
> still has a significant %idle as reported by "systat vmstat":
> 
>    9.9% Sy  47.1% Us   0.2% Ni   0.3% In  42.5% Id
> 
> The whole disk has the same data, so hexdump only generates
> 3 lines of output total.
> 
> I haven't yet figured out how to blame this result on the
> 3512 controller.  :-)

Maybe it's because this increase the time significantly between 2 reads ?
with dd of=/dev/null , the write will return immediatly, and dd will immediatly
issue another read (so only one syscall between 2 read). With dd | hexdump,
on the write to pipe the system may context-swich to hexdump, which will
return from its read, process it and go back to a blocking read. Then
the system will switch back to dd, which will issue the next read.
So 2 syscalls and 2 context switch in this case.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--