From owner-freebsd-hackers Wed Nov 11 07:47:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA28036 for freebsd-hackers-outgoing; Wed, 11 Nov 1998 07:47:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA28031 for ; Wed, 11 Nov 1998 07:47:07 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id IAA00103; Wed, 11 Nov 1998 08:38:43 -0700 (MST) Date: Wed, 11 Nov 1998 08:38:43 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199811111538.IAA00103@narnia.plutotech.com> To: Greg Lehey cc: hackers@FreeBSD.ORG Subject: Re: SCSI vs. DMA33.. X-Newsgroups: pluto.freebsd.hackers In-Reply-To: <98Nov11.134648jst.21907@ns.isi.co.jp> <199811110816.JAA01536@freebsd.dk> <19981111194213.H20849@freebie.lemis.com> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/3.0-BETA (i386)) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. 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. > Greg -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message