Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!lll-crg!hoptoad!gnu
From: gnu@hoptoad.UUCP
Newsgroups: comp.arch
Subject: Re: recent 386 timings from Intel
Message-ID: <1946@hoptoad.uucp>
Date: Mon, 30-Mar-87 07:35:17 EST
Article-I.D.: hoptoad.1946
Posted: Mon Mar 30 07:35:17 1987
Date-Received: Tue, 31-Mar-87 05:44:22 EST
References: <221@winchester.mips.UUCP> <2130@intelca.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 37

In article <2130@intelca.UUCP>, clif@intelca.UUCP (Clif Purkiser) writes:
>                  The system we used to run was an Intel Multibus I system 
> running Unix System V Release 3.0.  The CPU board was a 386/24 
> MultiBus I which has a 64 Kbyte direct-mapped write-through
> cache and 2-3 wait states for cache misses.

Hmm, let's make sure:  cache hits run with 0 wait states, cache misses
run with 2-3 wait states?  I'm curious about the construction of such a
cache.  What is the basic cycle time of the machine, and how many
cycles does a cache hit take?  Is it accessing main memory over the
Multibus, or on a local bus?  Is main memory static ram, or dynamic?

DRAMs take at least 100ns to fire up, so unless they are starting a RAM
access even before the cache is checked, that would seem to mean 100ns
(2 cycles at 20MHz) just for RAM access, not counting bus delay and time to
drive addresses to RAM chips (required if you intend to support a
reasonably sized main memory, e.g. >128 chips), and the time required
for the RAMs to be ready for the *next* address (another 100ns
or so).  And if the cache is running the RAM all the time even when
it hits, the DRAMs will not be ready to jump into action when the miss
comes along.

For example, in a 68020 design where the address lines zap straight out
into RAM drivers, with no cache at all, the DRAM cycle time is ~270ns,
or 4 clocks (1 wait state).  Adding a cache just increases the wait
states ON A MISS, though it speeds things up on a hit.

If these figures are true, I suspect the system is a "hot rod" with a
custom static RAM main memory on a local bus.  This amounts to building
the whole main memory out of expensive cache RAMs.  I'm willing to be
corrected, and/or to learn something new about memory design.

	John Gilmore
-- 
Copyright 1987 John Gilmore; you can redistribute only if your recipients can.
(This is an effort to bend Stargate to work with Usenet, not against it.)
{sun,ptsfa,lll-crg,ihnp4,ucbvax}!hoptoad!gnu	       gnu@ingres.berkeley.edu