ESDI controller recommendations

[Karl Denninger]

In article <68 at calcite.UUCP> vjs at calcite.UUCP (Vernon Schryver) writes:
>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.)  
.....
>> 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.

So tell me what systems do your "smart optimization" based on disk geometry
and format layout.  Please name _one_ single '386 ISA Unix system, or a
derivitive thereof, that even knows how to format (low level) the drives.
Oh, I guess 386/ix does, but it is rather stupid(tm) about it.  Even 386/ix,
if you look at the installation notes, recommends that you format from some
other tool than the OS if you can.

As for raw I/O going through the buffer cache, please name one Unix, again in 
the 80386 ISA environment that does this.  Just one, please?  Then find a
Unix for me that has an excellent buffer cache management scheme.  Again,
you may be looking for a while.

I haven't found one yet.  I've checked 386/ix, Bell Tech, AT&T, and SCO
ports.  All, in fact, either say outright or allude to the fact that raw
device access is unbuffered.

If a standard is defacto, it is just as much a standard as if it was written
in stone.

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

Huh?  How can you provide redundancy against a head crash EXCEPT by
mirroring the disk?  Explain your scheme please.  No fair cheating and using
disk "striping" -- 8 disk drives for each pack (one per bit!).  We're
talking about hardware that you can hang on a '386 ISA bus, not some
esoteric $2M system here!

The one system I saw to do this in the driver interface hit performance 
for > 50% over the base.  Yuck.  The DPT performance hit is a few percent.

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

In the page/swap partition?  Show me a Unix for the '386 ISA systems which
does this.  Every one I have seen so far goes right out to a raw, unbuffered,
I/O device.

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

What "symmetric multiprocessor" systems are you speaking of?  Is there even
a single such implementation that doesn't end up talking, ONE AT A TIME, to
the disk hardware?  Assume one (or two) disks here -- no fair comparing the
typical 80386 installation to a mainframe "disk farm".

If you talk to the disk hardware one processor at a time you must be, in the
end analysis, SLOWER than the "one for the disk, one for the data" crowd, as
you now have to arbitrate disk I/O between processors as well as physically
move the data!

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

Obviously you aren't working in the real world, and in addition are posting
about a utopia that isn't relavent to the purpose of THIS news group.

The people here, who read and post to this group, are working with and
talking about ISA 80386 machines.  That means AT bus.  Like it or not, there
are lots of compelling reasons for using the AT bus, and companies such as
DPT make it more than reasonable to do so.  Items like multiple-sourcing,
inexpensive price points, interchangability of operating environments (pick
your Unix), etc.

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

Only if your Unix knows how to use it intelligently.  None of the current
systems do.  Your argument sounds good, but doesn't cut it with today's OS
environments.  Again, you need to rethink within real-world constraints.

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

Such a machine IS a real computer.  It has 3-5X the power of a Vax 780,
which only a few years ago was quite a "real computer".  The 33 Mhz systems
are royal screamers, and put many of the so-called "workstations" to shame.
And they offer something NONE of the proprietary monsters do -- no hardware
single-sourcing.  That alone is enough reason for many people to buy into the
technology.

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

Cute.  Now please differentiate between:
	o A DPT board which crashes, losing the data in the cache.
	o A drive which head-crashes, losing the data on the disk.
	o A system which loses power, losing the data in the memory.

Oh, you can't tell the difference from the user perspective?  Wow.  Neither
can I.  "Purists" can be damned; it's the user's perspective that matters in
every case.  When you say "commit" you can't possibly achieve "commit to
stable storage" because there is no such animal!  The best you can do is
"commit to MORE STABLE storage".

Is your disk "proven correct"?  For how many hours? (what's it's MTBF?)  I
bet the DPT board has a higher MTBF than your drive -- it almost has to,
being that there are no moving parts!

Besides, no one said anything about RAM + battery.  The point was made that
the DPT board is a bad investment if you don't also have a UPS.  GIVEN the
UPS, however, the DPT is the best way to supercharge your 386 system that we
have seen, bar none.  IF your system crashes or panics, as they sometimes
do, the DPT board will finish flushing the cache to the drive(s) before it
shuts down.  No data loss has been seen here beyond what you would lose
anyway with a "straight" system.

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

We sell whatever the customer wants.  If someone comes to us and says "I
want a fast '386 based system, no holds barred", that is what we sell them,
yes.  We also sell "Standard" '386 systems, without these controllers, and
DEC gear, and lots of other stuff.  We are in the business of solving
people's problems, not pushing one board over another.  We, like most other
ISV's, operate in a real world bounded by many constraints -- most of them
set upon us by our customer base.

There are a lot of people who won't consider DEC RISC machines, or Sun
Sparcstations for the simple reason that they are single-sourced.  If you 
look at those systems you'll also find rather disappointing I/O performance 
compared to a DPT + ESDI disk + 33Mhz 386 machine.  

TRY one of the DPT boards before you go off half-cocked berating them.  You
might be (very pleasently) surprised.  Then try to find one of your utopian
multi-processor symmetrical '386 systems, for the same price, that beats the
DPT + 33Mhz 80386 for both CPU and I/O performance in the real world.  You'll
miss on the price, performance, or (more likely) both.

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