Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP
id AA1719 ; Tue, 23 Feb 93 14:55:05 EST
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!network.ucsd.edu!usc!cs.utexas.edu!geraldo.cc.utexas.edu!portal.austin.ibm.com!awdprime.austin.ibm.com!guyd
From: guyd@austin.ibm.com (Guy Dawson)
Subject: Re: [386BSD] What SCSI controllers _are_ supported?
Originator: guyd@pal500.austin.ibm.com
Sender: news@austin.ibm.com (News id)
Message-ID: <C2no1H.1JDo@austin.ibm.com>
Date: Thu, 18 Feb 1993 17:46:29 GMT
References: <QJufrAlBBh107h@hansford.com> <C2LoMH.46p@cs.mcgill.ca> <C2Luz6.1CzA@austin.ibm.com> <1993Feb17.214948.9390@fcom.cc.utah.edu>
Organization: IBM Austin
Keywords: 386BSD SCSI
Lines: 80
In article <1993Feb17.214948.9390@fcom.cc.utah.edu>, terry@cs.weber.edu (A Wizard of Earth C) writes:
> In article <C2Luz6.1CzA@austin.ibm.com> guyd@austin.ibm.com (Guy Dawson) writes:
> >
> >In article <C2LoMH.46p@cs.mcgill.ca>, storm@cs.mcgill.ca (Marc Wandschneider) writes:
> >> In article <QJufrAlBBh107h@hansford.com> murrayc@hansford.com (Charles H. Murray) writes:
> >> >In <count.729725567@mits> count@mits.mdata.fi (Bror Heinola) writes:
> >> >> I'll be transferring a 386BSD system to SCSI from WD1007 ESDI and
> >> >> I'd like to know what controllers are supported
> >> >> a) in kernel
> >> >> b) with special add-on drivers
> >> >
> >> >What about support for the Ultrastor 34F, VESA Local Bus SCSI-2 bus
> >> >mastering controller. I would love to see the performance of 386BSD
> >> >with this card.
> >>
> >> You left out a few buzzwords, like super-duper superscalar multi-
> >> segmented ultra buffering caching controller.
> >>
> >> Boy, would marketing be upset.
> >
> >At the risk of starting another Flame Fest(tm), who beleives that a
> >caching controller will improve performance much ( say 5% ) over the
> >caching that BSD does?
>
> If the controller can be accessed as fast as local memory, then yes, a
> caching controller will help above and beyond the caching done by 386BSD.
> The reasoning is that it's nearly always faster to hit memory locally
> than it is to hit memory on a card over a bus, and the caching done on the
> card, if it's optimized at all, is optimized for the way DOS accesses hard
> drives.
I've no problem with a cache controller being a big win for DOS...
>
> You may see some slight improvement on sequential reads; on the other hand,
> Julians driver supports sufficiant optimizations in the way controllers are
> used to make predictive read-ahead on a cached SCSI controller almost a 0
> win.
You are saying that with Julians drivers there is no gain?
That is what I am saying...
>
> You may also see a read performance increase due to hiding of the
> cylinder boundries by the caching (probably the best place for a cache on
> a controller to help you out, especially with a translated drive). To
> take advantage of this, you would have to disable some of the block I/O
> optimizations that try to compensate for cylinder boundries (as they would
> now tend to slow you down).
>
> A cached controller can, depending on the caching done, prevent important
> changes from hitting the disk (if it's write caching). In any case, LRU
> invalidation will only speed up the initial period of a high-use cycle
> (such as a compile), after which the buffers will saturate, and any write
> caching will perform like write-through anyway.
>
> The biggest DOS performance gain, prereading and caching .EXE files on the
> initial ready assuming that the entire file will be read, won't help in
> 386BSD, since the entrie image is not loaded at the same time. The pages
> are allocated, but they are marked fill-from-file.
>
Again I have no problem believing the benefits that DOS obtains. Its with
BSD ( ie good Unix ) that I'm questioning their use.
With a BSD program, if you execute the program, count to 10, or 100 and
re-execute the program you will almost certinally read the file from
the BSD cache... No cache can help you the first time you execute a
program.
I suspect that if we got face to face we would violently agree!
--------------------------------------------------------------------------------
Guy Dawson - Hoskyns Group Plc.
guyd@hoskyns.co.uk Tel Hoskyns UK - 71 251 2128
guyd@austin.ibm.com Tel IBM Austin USA - 512 838 3377
"Knolege is powef, Speling is unimportnt" via Pete W. De Bonte