Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!virtech!cpcahil
From: cpcahil@virtech.UUCP (Conor P. Cahill)
Newsgroups: comp.unix.i386
Subject: Re: ESDI controller recommendations
Message-ID: <1125@virtech.UUCP>
Date: 4 Sep 89 00:18:42 GMT
References: <121@mdi386.UUCP> <1474@wb3ffv.ampr.org> <4843@looking.on.ca> <68@calcite.UUCP>
Organization: Virtual Technologies Inc
Lines: 70

In article <68@calcite.UUCP>, vjs@calcite.UUCP (Vernon Schryver) writes:
> In article <1989Sep2.023511.24943@ddsw1.MCS.COM>, karl@ddsw1.MCS.COM (Karl Denninger) writes:
> > ...
> > o	The controller can be intimately familiar with the layout of the
> > 	disk itself....
> 
> All of the advantages of having a smart controller are in principle
> available to the operating system.

Yes, and they all steal cpu cycles from the user processes.  I paid alot 
for my heavy duty cpu and I would rather have it managing my windows and
compiling my programs then figuring out how to talk to my disk.

> > o	The controller can cache "raw" writes and reads, something that the
> > 	Unix system does not do.
> 
> Not true.  If there were a law requiring raw I/O to not use the buffer
> cache, then some UNIX kernels would be breaking it.

Raw device support is not provided by the kernel, it is provided by the
device driver.  Sometimes it makes sense for both the raw interface and
block interface to both pass through the buffer cache, but for disk i/o
all device drivers *should* not pass the raw i/o through the cache.  If 
they did, fsck would have lots of trouble (especially when it told you 
to reboot-no sync).

> > o	The controller can, if desired, physically mirror two disks, reducing
> > 	the probability of failure.
> 
> Even better, is to have the file system provide the correct rather than
> blanket redundancy.

I'm not too sure what you mean by correct rather than blanket redundancy, 
but the disk mirroring available will automatically fix/remap bad sectors
on both the master and/or mirror disk without any intervention on the part
of the user.  This is a very positive element for systems that will 
be placed in service in some remote region and left running for extended
periods of time without any local interaction. 

> 
> As others elsewhere continue to argue, given fixed and finite dollars (i.e
> price is an object), it is better to have two general purpose CPU's than a
> mixture of specialized ones.  An expression of this fact is the greater
> respect "symmetric multiprocessor UNIX'es" receive compared to "master-slave"
> or other modes.  Since most machines are sometimes CPU bound and not doing
> any I/O, a machine with two *86's working on user CPU cycles will be faster
> than a machine with one *86 for users and one asleep on the disk.

You are comparing apples and oranges. The dual/multi processor environments
were always setup with multiples of the same processor.  The master/slave
setup was pretty bad (at least on the one such setup I am familiar with) 
because only the master processor could perform most system calls.

However, in the scenario where a *MUCH CHEAPER* processor can be used
to offload some of the system i/o requirements this does not come into 
question.  Most mini's and mainframes use this mechanism to leave the
cpu doing what it does best.  

In particular the DPT comes with a 68000 processor which I *think* runs
for about $8 each and CAN handle all of the requiements dealing with
disk i/o.  

This is the same argument that is applied to the intelligent serial card,
which for about $500-900 will boost the serial i/o support on your 
system from maybe 2 19.2 lines to as much as 8 or 16.
-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+