ESDI controller recommendations

Vernon Schryver vjs at calcite.UUCP
Sun Sep 3 08:36:09 AEST 1989


In article <1989Sep2.023511.24943 at ddsw1.MCS.COM>, karl at 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.  In the dark past, before UNIX, file
systems paid attention to the geometry of the disk and even current head
positions when allocating blocks out of the bit map.  Some UNIX file
systems try to do a little of the same--consider cylinder groups.  What's
more, if a file system which allocates the file optimally during the write,
reads get faster.   (See the ancient Berkeley Project Genie papers.)  This
is not possible if the controller is too smart.  (Yes, I know SCSI drives
are often too smart, but they just as uppity for this wonderful controller.)

> 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.

> 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.

> o	In many cases the data is read back from the cache before it is even
> 	physically written to the disk!

Just like any cache scheme, no matter what level.

> o	The on-board processor takes the load of the transfer, ordering, and
> 	cache search instead of your physical processor [... giving more cycles
>	to users].

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.

Imagine a dual processor, with a kernel process running the code now on the
DPT board and the old disk driver talking to this daemon.  Put all of
the RAM in a common pool, but let the DPT-emulator grab as much as it
wants.  The dual processor would cost about the same, would never be slower
and usually make the smart controller, single processor look ridiculously
slow.  (Obviously, the AT bus would the wrong choice.)

> o	You can retune for a minimal number of buffers, giving even more RAM
> 	to the users.  This reduces the page fault rate and thus further
> 	increases performance.

Giving the same amount of RAM to the buffer cache instead of to the controller
would have the same effect.

> o	You can have more than 16MB in the system without trouble, and use
> 	nearly none of your "base" 16MB for disk cache....

Agreed.  On PC-AT/386 clones, this controller sounds like a neat idea.
Such a machine is not a "real computer."  (Never mind the vast (for me)
amount of my own $ I've spent on this one.)

> o	If the power fails and you do not have a UPS, you can get royally
> 	screwed.  Since the RAM onboard is not NV, quite a bit of data can
> 	be lost if the power goes off....
> 
> Some people have pointed out potential pitfalls in the setup when the system
> crashes or the like, or with databases.  These DO NOT EXIST.  The reason is
> simple -- the processor on the DPT board is independant from the main
> processor.  IF the system crashes, it crashes -- so what?  The DPT board
> will finish writing everything in the cache before it stops! ...

A purist might disagree with you.  "Commit" means "commit to stable
storage."  Does the DPT board have "proven correct" hardware and firmware?
Can it not crash like any other system?  However, being impure, I'll agree
if you say RAM+battery or RAM+capacitor+nonvolitile storage is stable
storage, whether it is made by IBM, Storage Tech., Legato, or DPT.

> Disclaimer:  We handle the DPT boards, as well as systems and the standard
> 	     controllers/drives.
> Karl Denninger (karl at ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
> Public Access Data Line: [+1 312 566-8911], Voice: [+1 312 566-8910]
> Macro Computer Solutions, Inc.		"Quality Solutions at a Fair Price"

Oh.  Now I understand your enthusiasm.  I trust you also sell UPS's.

Vernon Schryver
vjs at calcite.uucp    ...{pyramid,sgi}!calcite!vjs



More information about the Comp.unix.i386 mailing list