From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 11:39:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9D0E16A4CE for ; Tue, 19 Oct 2004 11:39:58 +0000 (GMT) Received: from tierra2.ng.fadesa.es (tierra2.ng.fadesa.es [195.55.55.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90D9E43D3F for ; Tue, 19 Oct 2004 11:39:52 +0000 (GMT) (envelope-from fandino@ng.fadesa.es) Received: from [195.55.55.163] ([195.55.55.163]) (authenticated bits=0) by tierra2.ng.fadesa.es (8.12.10/8.12.10) with ESMTP id i9JBdmi3000542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Oct 2004 13:39:50 +0200 Message-ID: <4174FD04.8040000@ng.fadesa.es> Date: Tue, 19 Oct 2004 13:39:48 +0200 From: fandino User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: gl, en, es MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20041015190638.C5A0E5D04@ptavv.es.net> <41715E7F.7060509@ng.fadesa.es> <20041018100045.f8koww0skcco0woo@www.sweetdreamsracing.biz> <4173D66F.6010200@DeepCore.dk> <4173F2E9.7010407@ng.fadesa.es> <417406E3.9010706@DeepCore.dk> In-Reply-To: <417406E3.9010706@DeepCore.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: user fandino from 195.55.55.163 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on tierra2 X-Virus-Status: Clean Subject: Re: FreeBSD 5.3b7and poor ata performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: fandino@ng.fadesa.es List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 11:39:59 -0000 S=F8ren Schmidt wrote: >> # dd if=3D/dev/ad4 of=3D/dev/null bs=3D1024k count=3D1024 >> 1024+0 records in >> 1024+0 records out >> 1073741824 bytes transferred in 31.090536 secs (34535970 bytes/sec) > > etc, and I get this: > 1073741824 bytes transferred in 18.488903 secs (58074934 bytes/sec) > 1073741824 bytes transferred in 14.956484 secs (71791059 bytes/sec) >> I'd like to know wich is you opinion about this. > > If you run a stock generic kernel with the debug (WITNESS etc) taken ou= t=20 > you should see the same raw performance as I do. I redid all tests with __RC1__ and performance is as bad as before. > Now, raw performance is one thing, filesystem I/O something entirely I think the problem is with raw performace, just see this example with a test raid0. Each disk by separate has a throughput of 26000 K/sec,= with /dev/stripe/test they have a throughput of 15000 K/sec each (raid0 throughput 30000 K/sec) and with four disks 7500 K/sec each (30000 K/sec again). # dd if=3D/dev/stripe/test of=3D/dev/null bs=3D1024k count=3D1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 30.072215 secs (35705445 bytes/sec) There is a constant limit of 30000 K/sec independent of the number of disks used. simply it doesn't makes any sense. With two disk I'd must have approx. 26K+26K=3D52 M/sec and with four 26K+26K+26K+26K=3D104 M/sec Other systems like OpenBSD had a good throughput 55000K/sec by disk I send you in another email with all info that you need. Regards,