Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 11 Nov 1998 08:38:43 -0700 (MST)
From:      "Justin T. Gibbs" <gibbs@narnia.plutotech.com>
To:        Greg Lehey <grog@lemis.com>
Cc:        hackers@FreeBSD.ORG
Subject:   Re: SCSI vs. DMA33..
Message-ID:  <199811111538.IAA00103@narnia.plutotech.com>
In-Reply-To: <98Nov11.134648jst.21907@ns.isi.co.jp> <199811110816.JAA01536@freebsd.dk> <19981111194213.H20849@freebie.lemis.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811111538.IAA00103>