Date: Tue, 19 Oct 2004 20:50:17 -0600 From: Scott Long <scottl@freebsd.org> To: Xin LI <delphij@frontfree.net> Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 5.3b7and poor ata performance Message-ID: <4175D269.208@freebsd.org> In-Reply-To: <20041020024908.GA3797@frontfree.net> References: <41715E7F.7060509@ng.fadesa.es> <20041018100045.f8koww0skcco0woo@www.sweetdreamsracing.biz> <4173D66F.6010200@DeepCore.dk> <4173F2E9.7010407@ng.fadesa.es> <417406E3.9010706@DeepCore.dk> <4174FD04.8040000@ng.fadesa.es> <20041019104525.ikgw8kcw8sw480os@www.sweetdreamsracing.biz> <4129.192.168.0.188.1098211592.squirrel@192.168.0.188> <20041019200908.GA655@frontfree.net> <4259.192.168.0.188.1098217092.squirrel@192.168.0.188> <20041020024908.GA3797@frontfree.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Xin LI wrote: > Hi, Mike > > On Tue, Oct 19, 2004 at 04:18:12PM -0400, Mike Jakubik wrote: > >>Xin LI said: >> >> >>>Unfortunatelly I can reproduce similiar problem when using Ultra320 under >>>mpt(4) and a version of Adaptec's SCSI card (maybe aic, or something else, >>>which I have to go to my office to find out). Additionally the problem is >>>not FreeBSD specific, with a Linux installation, it shows poor performance >>>too. (No RAID configuration, though). >>> >>>I found that block size does influence performance greatly. With a block >>>size of 131072 I got peak read performance at about 70MB/s, but that's >>>all. >>>I did not have the necessary knowledge at the time I have did the test >>>last >>>month, so I got only the result and thought that I have made something >>>wrong and hoped someone to correct me with no luck :-( >> >>Hrm, i tried your block size, and the performance is even worse: >> >># dd if=/dev/da0 of=/dev/null bs=131072 count=2000 >>2000+0 records in >>2000+0 records out >>262144000 bytes transferred in 8.688651 secs (30170852 bytes/sec) > > > You may want to try other block sizes, like 65536, 262144, 524288, 1048576 > or so. The peak performance block size depends heavily on hardware... > > Cheers, This won't really matter. physio will chop the blocks up into 128k segments, and GEOM will cut them again into 64k segments. Other than a minor amount of coelscing in these stages, it won't make a difference. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4175D269.208>