From owner-freebsd-hackers Thu Nov 12 16:42:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA22120 for freebsd-hackers-outgoing; Thu, 12 Nov 1998 16:42:27 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from papillon.lemis.com (papillon.lemis.com [192.109.197.159]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA22100 for ; Thu, 12 Nov 1998 16:42:20 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by papillon.lemis.com (8.9.1/8.6.12) with ESMTP id SAA02274; Thu, 12 Nov 1998 18:22:12 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.1/8.9.0) id SAA28508; Thu, 12 Nov 1998 18:22:38 +1030 (CST) Message-ID: <19981112182238.J463@freebie.lemis.com> Date: Thu, 12 Nov 1998 18:22:38 +1030 From: Greg Lehey To: "Justin T. Gibbs" Cc: hackers@FreeBSD.ORG Subject: Re: SCSI vs. DMA33.. References: <98Nov11.134648jst.21907@ns.isi.co.jp> <199811111538.IAA00103@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199811111538.IAA00103@narnia.plutotech.com>; from Justin T. Gibbs on Wed, Nov 11, 1998 at 08:38:43AM -0700 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 11 November 1998 at 8:38:43 -0700, Justin T. Gibbs wrote: > In article <19981111194213.H20849@freebie.lemis.com> you wrote: >>> I must say that the newer UDMA IDE drives has come a long way >>> lately, they perform at least as good as their SCSI counterparts. >>> The only thing that they cannot do is overlapping commands, but >>> given EIDE's much smaller cmd overhead, I'm not sure this has >>> any significance at all in practice. >> >> This last point would appear to be borne out in my measurements >> earlier today. > > You had all of 1 command going to each disk. That doesn't give > you any per-device overlap. Sure. I was referring to the command overhead, not the effect of overlapped commands. > If you really want to see the effect of overlapped commands, run a > benchmark through the filesystem that causes lots of commands to be > generated. Do it with tagged queuing and without. If your devices > support a reasonable number of transactions, the effect of disabling > tagged queuing on latency is quite dramatic. I once introduced a > bug into CAM that effectively disabled tagged queuing. For several > days I couldn't understand why my interactive performance was so > lousy during large compile runs. I think that the testaments on > this list and others about the dramatic improvement CAM has made to > the performance of high load, random seek, workloads also shows the > effectiveness of overlapped I/O. The main reason CAM performs so > well is the order of magnitude increase in the number of concurrent, > per-device, transactions the system supports. No doubt, and that's what I intended to do next. Unfortunately, I've just fallen off the net (massive phone cable damage out in the street), so I don't can't download any benchmarks. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message