Path: utzoo!attcan!uunet!cs.utexas.edu!csd4.csd.uwm.edu!uxc.cso.uiuc.edu!tank!eecae!upba!dsndata!unocss!mlewis
From: mlewis@unocss.UUCP (Marcus S. Lewis)
Newsgroups: comp.arch
Subject: Re: cache speed
Message-ID: <1493@unocss.UUCP>
Date: 22 Aug 89 02:10:07 GMT
References: <1736@crdgw1.crd.ge.com>
Organization: U. of Nebraska at Omaha
Lines: 47

From article <1736@crdgw1.crd.ge.com>, by oconnordm@CRD.GE.COM
 (Dennis M. O'Connor):
> roy@phri (Roy Smith) writes:
> ] Cache is, by definition, a compromise.  If you really want to build
 
> Summary : it's currently impossible to build a 16-megabyte NMOS,

Gentles, please, my apologies.  I had no intention of starting a war here
of all places.  In my original post, I mentioned a co-worker "building"
a hi-perf 386.  This is, at least in THIS forum, a misstatement.  I
have received lots of mail, almost all of which ended at least in asking
why not use the 386 cache controller.  Now I see my mistake.

He is not _DESIGNING_ a system.  He is looking over motherboards, and I
was questioning (a) why he needed 128K cache, and (b) why it needed to
be 15 ns for a 33 MHz CPU.  Especially since the board has the 15 ns
chips as an option (upgrade from 25 ns).  I'm trying to save my company
some money here.  He's buying the stuff, but I get to assemble it into a
machine.  We did this once before, with a Texas MicroSystems 16 MHz CPU
in a passive backplane.  He wants 33 MHz, and the only place he can get
it NOW is as a MB system. 

We have a "strategic product", a voice-response system based on this
machine, currently running 8 channels under MS-DOS, and the CPU is
having trouble keeping up.  The next step is to get some faster voice
boards, port the existing system to a faster setup, then convert the
whole shot to some Unix variant.  My contention is that 128K cache MAY
help in the MS-DOS version, since it is one humongo program, but in the
Unix version it will be multiple tasks, scheduled by Unix, in which case
I doubt that the cache is going to be all that useful, at least not in
that size. 

Is this clearer? I am still somewhat in the dark, having lurked here for
over a year, about some of the terminology you folks use.  Like, (dumb,
yes, but I'm a system manager) what do you mean by a cache line? And how
does the controller deal with an invalidation: is there a penalty on a
real miss, and if so does the larger cache increase that penalty?

But please don't argue about it.
Thanks a bunch.  This has been a very productive lurk.
Marc

-- 
Na khuya mne podpis'?                 |  Internet: cs057@zeus.unl.edu      
                   preferred machine->|  UUCP:     uunet!btni!unocss!mlewis
Go for it!                            |  Bitnet:   CS057@UNOMA1            
---------------------------------------------------------------------------