🚀 go-pugleaf

in article <21936@cup.portal.com>, cliffhanger@cup.portal.com (Cliff C Heyer) says:

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

Generally, UNIX system do cache flushes when they enter kernel space, and they
MUST between user tasks, since the address spaces are aliased.  Caching still
helps under UNIX, maybe even considerably depending on the main memory design,
but you won't get the maximum possible performance out of a system under UNIX.
Check out MIPS magazine, they tend to benchmark '386 systems under a variety
of UNIX derivitives and raw (program loaded in '386 native mode from MS-DOS);
the raw case always performs better.  Of course, chances are, a benchmarking
program will likely fit entirely in a 32k or 64k cache.  You have to ask 
yourself if a little better raw speed is enough to drive you from UNIX to 
MS-DOS :-).

Another issue may be disk drive speed.  On the 68030 systems I work on, I've
seen hard disk speed drop by a factor of 2-3 when going from our native OS to
UNIX.  I'm not sure any '386 PCs have fast enough disk hardware for this to 
make a difference, but it could.

> 2. Is memory technology (cost/speed ) lagging behind microprocessor 
> technology? 

Undoubtedly.  Try running a 50MHz '030 (real, sitting next to me on my desk
here) without wait states on any memory.

> 3. Is it impractical (cost and/or size) to put 40 256KB 25ns SRAMs (no 
> refresh overhead and cycle time=access time) up for main memory? 

Yes.  First, it'll cost a big bundle.  Second, I don't think you really want
to run UNIX with only 1 megabyte of real memory; I've found it's really not
what I'd call comfortably fast without about 4 megabytes, at least on our
68030 systems.  

> In other words, is it cheaper to implement paged (PMRAM, SCRAM) or 
> interleaved schemes to reduce wait states rather than use 40 SRAMs? 

By far.  

> It seems like alot of trouble to go to...but how much do SRAMs cost?

I think they're somewhere on the order of 5x the cost for the same amount
of memory, and they also take up at least twice the board space.  Also,
SRAM densities are a generation or so behind DRAM densities (256k x 4
SRAMs are almost as easy to come by today as 1 Meg x 4 DRAMs).

> 4. Are any board makers making (or have made) motherboards with ESDI and/or
> SCSI interfaces ON BOARD to bypass the 8MHz AT bus? 

Even that's not enough.  SCSI, for example, is still only 8 bits wide, and it's
maximum transfer rate of 4 megs/second is in the same ballpark as the fastest
AT buses.  That's all a secondary issue as long as you're multitasking; the real
concern is how long disk I/O ties up the main bus.  The best thing to do here is
read a reasonable number of bytes over the SCSI bus into a FIFO, then transfer 
that data over you're full bus width via DMA (another reason to avoid the AT 
bus).  This is what Amiga hard disk controllers do, and we get up to 900k/sec
through the filesystem using asynchronous SCSI (1.5 megs/sec).  I've heard of
PC systems (ALR I think) that get around 750k/sec, I suspect they do something
clever.

> 6. If you whipped out your trusty soldering gun and anti-static gear and 
> changed all your memory chips to 25 ns SRAMS(on a 33MHz machine w/no cache)
> would the wait states go away? 

Well, first of all, they woundn't physically fit.  You'd really have to throw
out the whole memory subsystem.  There's undoubtedly some logic that sets the
memory cycle time.  And on top of that, even if the memory did fit, there's
no guarantee that a DRAM bus which cycles in 140ns would still work with SRAM
and 40ns cycles times.

> 7. The PC manufacturers never talk about parity error checked memory, 

Most PCs use partity checked memory, which lets them detect a memory error
(and increases the chance of such an error by 1/9), but doesn't let them do
anything about it.

> Harvard A.(separate data/instruction cache), 

This isn't an advantage as an external cache unless you're CPU has external
I and D busses.  The only one I know of that does is the Motorola 88100.  While
68030s have an internal Harvard design with separate I and D caches, the '386
doesn't have any internal caching.  While it's no problem for UNIX, apparently
MS-DOS would have some great trouble with split caches, which is the main
reason given for the unified cache built into the 80486 (though I suspect the
other reason is that Intel might rather sell you a different chip for non-PC
applications, so it wouldn't do to make the 80486 overly fast, would it...).

> Are PC mfgs behind the times? Or is this because of all the canned stuff 
> from the east.

Most of the canned stuff comes from California chip fabs.  And I suspect many
PC makers are behind the times.  The rest of them are struggling with the
architecture.

>    >operates FCC class B.

Whaddya expecting, miracles?!?
-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
                    Too much of everything is just enough