From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 15:00:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32044106566B for ; Wed, 2 Sep 2009 15:00:25 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id CC2158FC13 for ; Wed, 2 Sep 2009 15:00:24 +0000 (UTC) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n82F0KTJ034364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Sep 2009 17:00:20 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n82F0Io9047260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2009 17:00:18 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n82F0Iq7067183; Wed, 2 Sep 2009 17:00:18 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n82F0HZ2067182; Wed, 2 Sep 2009 17:00:17 +0200 (CEST) (envelope-from ticso) Date: Wed, 2 Sep 2009 17:00:17 +0200 From: Bernd Walter To: Olivier Smedts Message-ID: <20090902150017.GU60240@cicely7.cicely.de> References: <4A9E5F34.2090700@razorfever.net> <20090902141138.GA15045@dmr.ath.cx> <367b2c980909020736i60b64563xc4fec6d11e3dae2b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <367b2c980909020736i60b64563xc4fec6d11e3dae2b@mail.gmail.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.000, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: "Derek \(freebsd lists\)" <482254ac@razorfever.net>, Emil Mikulic , freebsd-current@freebsd.org Subject: Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 15:00:25 -0000 On Wed, Sep 02, 2009 at 04:36:29PM +0200, Olivier Smedts wrote: > 2009/9/2 Emil Mikulic : > > On Wed, Sep 02, 2009 at 08:04:04AM -0400, Derek (freebsd lists) wrote: > >> Hi, > >> > >> I've been testing the new siis driver, and I have found no > >> appreciable performance change, using dd as a measure of "raw" > >> performance. > >> > >> I get about 40MB/s read, and 30MB/s write.  See attached > >> bench-*.txt files. > > > > [...] > > > >> ada0: ATA/ATAPI-8 SATA 2.x device > >> ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) > > > > Huh, I have the same disk: > > > > # dmesg | grep ad4 > > ad4: 1430799MB at ata2-master SATA300 > > > > Sequential read on a disk this size should be around 120MB/sec at the > > outer tracks: > > > > # dd if=/dev/ad4 of=/dev/null bs=128k count=5000 > > 655360000 bytes transferred in 5.171389 secs (126728039 bytes/sec) > > > >> Also I find it surprising that my gmirror read is only 40MB/s, > >> and not 60-80MB/s, any thoughts on this? > > > > Stripe will give you higher throughput. > > Mirror will give you more random seeks per second. > > And higher read throughput. This is a myth and not true for linear access in the general case. A disk usually lays the track reversed order to increase read throughput. Once the head is positioned it reads data into cache until the asked block is reached, so it already has more or less of the following blocks in cache. If you need the following block you better ask the same disk, because at average it already has the half track in cache. If you ask another disk it has to do a physical read first. To really increase linear throughput you need to preread data at a large offset (knowing the physical layout of the drive), but since in real world this is usually data of a completely different file it doesn't make much sense. For short range switches you just ask two disks for different blocks, but require them to issue the same physical reads. Of course you can double the read throughput, but only tuned for contructed cases. Striping is different, because say first strip is accessed from disk 1 and second stripe from disk 2. This reduces performance, because unlike disk 1 disk 2 has the following block not in cache, but for upcoming blocks you win from the cummulative preread cache. But real world filesystem access rarely is that linear, so even then it mmight be better to increase the stripe size large enough to not take the linear win, but also not have the disk switch loss. In real world you usually can win performance from random access in both cases and random access is what you almost always really want to increase. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.