From owner-freebsd-scsi Fri Mar 12 16: 0:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id B1C8814E8B for ; Fri, 12 Mar 1999 16:00:43 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id QAA34730; Fri, 12 Mar 1999 16:58:44 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903122358.QAA34730@panzer.plutotech.com> Subject: Re: SCSI disk oddities and Buslogic problems.. In-Reply-To: <199903122312.PAA12555@mina.sr.hp.com> from Darryl Okahata at "Mar 12, 1999 3:12:25 pm" To: darrylo@sr.hp.com Date: Fri, 12 Mar 1999 16:58:43 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Darryl Okahata wrote... > sthaug@nethelp.no wrote: > > > Chris Csanady wrote: > > > In this case, I have found that while running the following commands that > > > the data transfer is very erratic. > > > > > > dd if=/dev/rda2s3 of=/dev/null bs=128k (or any place on the disk..) > > > > > > iostat -w 1 da2 > > > > No problem with a 9 GB model here. Typical iostat output: > > I have seen strange things with 3.1-RELEASE (I've yet to try > -current), and tagged queueing. Using 3.1-RELEASE, an Adaptec 7895 > controller (built into my Gigabyte 6BXDS motherboard) and two IBM > Ultrastar 9ES drives striped together using vinum, I get strange > performance numbers using iozone (yeah, iozone isn't very good for > benchmarking striped drives, but I'm just using it as a zero-th order > gauge). > > Individually (if I do not use vinum and just newfs a single drive), > I get around 11MB/s write, and 13MB/s read. No problem here. Yep, sounds fine. > If I stripe the drives together using vinum, and use the default > newfs values, I get something like 3.7MB/s write, and 16MB/s read. The > write throughput sucks. If I run newfs with 4K frag sizes, the write > throughput jumps up to around 7MB/sec. Better, but still not great. > > However, if I go into the BIOS and disable SCSI disconnect, the > write throughput jumps back up to 11MB/s. Much better, but disabling > disconnects kinda defeats the purpose of striping .... > > The only thing I can think of is that tags are somehow involved, as > disabling disconnects also disables tags. But it would also decrease the number of simultaneous transactions that vinum has to process. I think it's kinda hard to pin this on CAM or the drives, since the drives behave okay without being striped. How does the array perform if you stripe the disks together using ccd? It may just be a problem with whatever stripe size or parameters you're using with vinum. The fact that you got a vastly different result by upping the frag size to 4K points to that. Perhaps you just need to experiment a little more with stripe sizes and filesystem parameters. You may want to talk to Greg Lehey about this. He'll probably have some suggestions on vinum performance tuning. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message