Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Oct 1999 17:13:19 +0200 (MET DST)
From:      Gerard Roudier <groudier@club-internet.fr>
To:        Matthew Jacob <mjacob@feral.com>
Cc:        "Kenneth D. Merry" <ken@kdm.org>, "Chris D. Faulhaber" <cdf.lists@fxp.org>, Andrew Gallatin <gallatin@cs.duke.edu>, scsi@FreeBSD.ORG
Subject:   Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300
Message-ID:  <Pine.LNX.3.95.991017164517.3181A-100000@localhost>
In-Reply-To: <Pine.BSF.4.05.9910161238340.11481-100000@semuta.feral.com>

next in thread | previous in thread | raw e-mail | index | archive | help


On Sat, 16 Oct 1999, Matthew Jacob wrote:

> > Hmmm... This can only happened with too old or poor designed SCSI
> > controllers. Well designed SCSI controllers do not interrupt uselessly.
> > About disabling SCSI disconnections, I would have been glad not to have
> > read that. Note that I am not going to ever choose a SUN originated
> > system for numerous reasons. ;-)
>=20
> I'm talking about 14 years ago, btw... So, before you slam Sun for this,

At that early time, they could use low-cost processors like Z80 or 68XX
for the handling of SCSI phases sequence. Given skilled ingenieers, they
couldn't miss that, in my opinion.

> remember it was pretty good for the time and price class. I would buy Sun=
s
> *now*, but for other reasons and for certain properties that may popular
> OSS systems have no clue about yet.

A supplier that does not apply standards or reinvent parts of standards is
a great burden for the industry.

> > > I suspect that the right thing here is to to ultimately do completely
> > > adaptive scheduling with hints- this would also solve the arguments I
> >=20
> > May be, a simple but kind bug that add some mess-up to disksort would
> > solve the problem. :-)
> >=20
> > > constantly have with Matt Dillon over whether MAXPHYS is too small at
> > > 128KB (it most certainly is if you have a job mix that's mainly large
> > > sequential writes or reads)- but until that point, document the tools=
 that
> > > allow you to tune things and tell users "Knock yerself out... have a =
great
> > > time!"
> >=20
> > I have measured 35MB/s throughtput on a 80MB/s LVD SCSI BUS using 4K
> > actual IO chunks. This let me think that 64 KB is not that small given =
not
> > ridiculouly high IO latency. May-be for Ultra-160 (and probably for fut=
ure
> > Ultra-320), 64KB will be to small.
>=20
> Again- it depends. I doubt that it's the bus speed that makes this a fine
> thing here- it's very likely the faster microprocessors on the newer LVD
> disks. Fibre Channel disks have some of the same properties, but even
> better is the fact that non-data phases pretty much don't exist in
> fibre channel, so there's no such thing as blowing through a 4k data phas=
e
> at 40Mhz+ only to sit and pick your nose for hundreds of microseconds for
> status and message in and bus settle delay and arb delay.....

In most applications, the average actual IO size is less than 8KB. So,
unless most are rewritten for making good use of large actual IO chunks,
such a facility will not make most existing systems faster.
For now, only a small number of applications can take advantage of
actual IOs larger than 64 KB.
On the other hand, SPI is still widely used on our planet and will
probably still be used for a long time.
With Ultra-160, 8KB can be transferred in 50 micro-seconds. Using
interfaces with high latency will not allow to take advantage of this
technology for real applications.

G=E9rard.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.991017164517.3181A-100000>