Cache board .vs. caching kernel (Re: ESDI controller recommendations)

Karl Denninger karl at ddsw1.MCS.COM
Tue Sep 5 15:29:34 AEST 1989


In article <71 at calcite.UUCP> vjs at calcite.UUCP (Vernon Schryver) writes:
>In article <1989Sep4.024559.13279 at ddsw1.MCS.COM>, karl at ddsw1.MCS.COM (Karl Denninger) writes:
>> > ...[a loud rebuttal]...
>
>I got Mr. Denninger's dander up.  Be careful or thick skinned when not
>complimenting what people sell.  He is obviously wrong and inconsistent on
>several technical issues, but such technicalities are not germane to what
>he is saying.

How about listing those examples I asked for?  One Unix Operating System, 
commercially available for the 80386, that has these wonderful changes in it
you espouse?  One Unix for the '386 that doesn't bypass the buffer cache for
raw I/O requests?  A better solution for the 386 systems of TODAY,
available NOW -- than the DPT boards for greatly increasing I/O performance?

Tell us about this wonderful "fixed" Unix.  Where can I buy it?  If it 
doesn't exist, then all you are doing is playing devils' advocate and not 
furthering the exchange of information here.

How about discussing what I am talking about rather than a personal attack?
Or is "ad hominen" the order of the day here in this nice technical group 
too?

Yeah, you got my dander up.  You're out here spouting off at the fingers
about some utopian operating system which we can't buy.  Some enhancement to
the kernel that we can't make.  The rest of us in this newsgroup operate in
the real world, not a utopia with kernel source access.

As for incorrect on technical issues, which ones?  The assertion that there
is no better way to handle drive failure than mirroring?  The assertion 
that given the _current Unix systems available for ISA 80386 machines_ the 
DPT board is your best shot at excellent I/O performance?  The assertion that 
the idea of "commit to stable storage" is a crock given the inherent failure 
possibilities in all fixed storage using today's technology?  I'd like to 
hear your refutation of these points.

>As I agreed in the article which got him excited, the DPT controller sounds
>good for small, slow computers such as this 20MHz, 8MB clone, for those of
>us without the money, time, talent, or source to fix the SV kernel.  

Ah, now here comes the qualification.  The truth of the matter is that I,
or anyone else, don't give a whit about what one can do with the source 
to System VR(x).  Do you have a spare $65,000 laying around for a source 
license, and a lot more for that binary redistribution license?  I 
thought not.  Neither do 99.9% of the people out there who are reading 
this newsgroup, or who buy and use these systems.

Lots of us have the talent to fix the kernel.  Not many of us have the time,
source, or money.  Even fewer can support that change with a large customer 
base, and thus we have to, out of necessity, turn to those companies
(SCO/ISC/Bell) for our Unix(es).  If you can do it better, buy a source
license, binary redistribution rights, and blow the rest of the market 
out of the water.  Until you do that, you've got little room to complain
or nit-pick about real-world solutions to real-world problems.

>This
>part of my life qualifies, so I would happily accept one for an extended
>evaulation.  However, the simple professional honesty required in another
>part of my life compels me to say the DPT controller is architecturally
>wrong.  That AT&T et al currently make it useful and desirable is irrelevant.
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>There is no reason to lie to customers and say it is more than a neat and
>cheap kludge around design flaws in some versions of SVR3, or to claim
>those flaws are part of "UNIX."

Design flaws?  Look, if you don't like Unix, then go run VMS.  (1/2 :-)
Even better, if you like to espouse such drivel, why don't you hire yourself
out to AT&T, SCO, ISC, et.al.  Why haven't you do this two + years ago?

The simple professional honesty in my working life requires that I recommend
use and sell that which works, now.  A person who comes to us (or anyone else) 
needing a solution isn't going to accept, nor should they, a "well, it might 
be fixed in a few years, but right now it sucks.  Since you can't afford the
$200k solution, you just have to wait."

When you can hold out your "fix" for the "design flaws", for sale (or free), 
and in addition can support the monster you create, then and only then can 
you complain about the DPT (or other caching controllers) being a kludge and
unsuitable for "real computing".  Until then we'll use what works, thank you
very much.

>From your comment above it's obvious you've never used one of the DPT 
boards.   So this entire discussion is academic; you don't have any
experience with the product.  How can you flame something you've never 
even seen or tried?!

>In 1989, "fast" uniprocessor workstations are >=20 times a VAX 780, 3-5 times
>faster than 386 clones.  True, they use 88K's, SPARK's, or MIPS-R3000's
>instead of 386's and cost more than $2,500 (but <$25,000).  You can buy
>multiprocessor workstations well over 100 VUPS (1VUP=1VAX 780).  

Ok, I'll bite.  How much for that 100 VUPS workstation with your "fixed"
version of Unix?  Is this, again, an academic discussion?

(You haven't seen the 80486 systems yet, have you?  ISA bus, 30-50 VUPS, 
available before Christmas 89, base cost under $12k.  But I digress...)

If they're not ISA 80386 systems, then there is no point to discussing them
here.  Take it to comp.arch where it belongs.  This group is for discussion
of machines that are ISA based and use a '386 processor (and have the
additional quality of costing a few thousand, not $25k).  Some of us bought
them because we need or want to run (horror of horrors) MSDOS through VP/IX
or Simultask while we're using our Unix.  Try _that_ trick on your 
Sparcstation.

Comp.unix.i386 is also for discussion of REAL Unix operating systems 
available for these machines, not dreams that someone has in their head, 
or something for a minicomputer that isn't available.  

> At least
>one such SVR3 until recently mapped raw disk I/O to cooked.  (Disagreement
>on that point from a PC VAR are boring to a hack paid to work in that kernel.)

Until recently, eh?  Why did they change it back?  Hmmmm....  

You know, someone just struck me as obvious.  If you buffer raw writes, then
you also need that UPS.  You see, many DBMS systems work with raw I/O....
there goes your full buffer cache when the lights go out or the system
panics.  Hmmm....  Even the UPS doesn't help when you panic, does it?  Oh 
well.  

Rather clever of that DPT board -- how it doesn't use the same memory space 
as the kernel, so a corrupt data area in the kernel can't crash the 
buffers.......and it's smart enough to write out it's cache even after the
main processor halts.  Now _that_ would be a good trick for your "fixed"
kernel to pull off.  

I daresay that the DPT solution (off-board cache processor) is superior
than your idea for the reason of greater data security alone.  Unix systems
do panic, you know.  Not often (we hope anyway), but it does happen.

>That we are now stuck with no more than half-dozen VUPS is no reason to get
>religous.  This is comp.unix.i386, not biz.att or biz.MacroComputerSolutions.
>People here snear at the silliness of DOS extended memory.  Let's not
>permanently wed an analogous kludge for what are hopefully temporary O/S bugs.
>
>Vernon Schryver
>vjs at calcite.uucp     or    ...!{sgi,pyramid}!calcite!vjs

You bet it's not biz.*, but it's also not bash.att or bash.mcs.  You've done 
nothing other than proselytize about systems that aren't under discussion 
and imaginary operating systems we can't purchase.  Until either of those 
items change, your points are irrelavent in relation to the topic of 
this group and the merits (or lack thereof) regarding the DPT boards.

You know, something amazing was just revealed to me ("grep" time).  Guess 
what "calcite" is, and what "Rayolite Systems" has as their Usenet machine.
Why, a '386 system running Microport SV/386!  So much for those systems 
(hardware and software) you would like to claim are "far superior", eh?  
Why aren't you using one of them?   Heh, you're even listed as the
administrator of this "incompetent" Unix product.
(chuckle). 

Followups redirected to alt.flame where they belong.

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



More information about the Comp.unix.i386 mailing list