Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.sys.ibm.pc
Subject: Re: UPDATE
Summary: partial answer
Message-ID: <295@crdos1.crd.ge.COM>
Date: 7 Sep 89 14:38:02 GMT
References: <21931@cup.portal.com>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Organization: GE Corp R&D Center
Lines: 79

In article <21931@cup.portal.com>, cliffhanger@cup.portal.com (Cliff C Heyer)
writes:

	[ this is an answer to part of his posting ]

|  1. UNIX (or any multitasking OS) and the effects of 
|  the on-board cache:
|  
|   	While multitasking, does flushing the cash waste a 
|  measurable amount of run time or is it 
|  insignificant compared to swapping, paging, and/or 
|  other overhead? In other words, is the cache still 
|  beneficial even though it is being flushed? (I 
|  assume "yes" since minicomputers such as all VAX 
|  models have them.)

  I assume you mean disk cache. Yes it helps a lot, yes it causes a big
slowdown in the system when it flushes. Tune you disk cache size to fit
your needs.

	[ questions about memory ]

  64k cache gives 90+% cache hits. Coupled with interleave or column
static gives something like .05-.30 wait state average depending on what
you're doing.

|  4. Are any board makers making (or have made) 
|  motherboards with ESDI and/or SCSI interfaces ON 
|  BOARD to bypass the 8MHz AT bus? Also hopefully 
|  this mfg. would include shadow RAM (BIOS & video) 
|  and extended/expanded memory that is as fast as 
|  main memory. (eg. add on memory boards have same 
|  cycle time as the first 2MB.)
  Mylex makes a controller which goes on the 32 bit bus and has a load
of cache on it. You can set the UNIX cache very small and still have
good performance. After looking at cache performance I'm not sure you
buy anything this way, at least not $4k worth, but it's there.
|  
|  5. I assume the ONLY thing that makes the 33MHz PCs 
|  faster is the 25 ns cache. Otherwise, with 70 ns 
|  DRAM the BEST you could do would be run as fast as 
|  a 16MHz 80386 PC (62 ns) but with lots of wait 
|  states. In other words, memory cycle time limits 
|  non-cache CPU performance to that of a 16MHz 80386.
  On longer instructions the faster speed still buys performance. Not as
much as you get with faster memory, but still some. It depends on your
instruction mix, since pure CPU stuff will run full speed even with
several wait states due to the pipeline. When you start branching and
accessing data in memory you slow down.
|  
|  6. If you whipped out your trusty soldering gun and 
|  anti-static gear and changed all your memory chips 
|  to 25 ns (on a 33MHz machine w/no cache) would the 
|  wait states go away? OR is the timing part of the 
|  hardware architecture?
  Some boards can have the w/s changed. It's not clear how much you
would gain.
|  
|  7. The PC manufacturers never talk about parity error 
|  checked memory, ECC memory, separate 
|  data/instruction cache, data write-thru cache, 
|  write buffers (CPU can go on after issuing initial 
|  memory instructions), and multi-word memory 
|  transfers. Are they behind the times?
  As far as I know the PC based machines all use parity. I believe there
are ECC AT bus memory boards available, but I didn't save the article.

  Conclusion: if you want a big jump in power, wait for a 486. Although
it's not obvious, a hardware trace on the wait line of most cached 386s
will show that you are only losing 10-15% *at worst*. Before spending a
lot of money trying to get faster everything you can start with
something inherently faster.


-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
"The world is filled with fools. They blindly follow their so-called
'reason' in the face of the church and common sense. Any fool can see
that the world is flat!" - anon