NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/graphics/9545

Internet Message Format | 1992-09-08 | 2.7 KB

Xref: sparky comp.graphics:9545 comp.sys.ibm.pc.hardware:23774
Newsgroups: comp.graphics,comp.sys.ibm.pc.hardware
Path: sparky!uunet!spool.mu.edu!yale.edu!ira.uka.de!math.fu-berlin.de!informatik.tu-muenchen.de!regent!mch
From: [e-mail] (Michael Hermann)
Subject: Re: 486 external cache
Message-ID: <[e-mail]>
Sender: [e-mail] (News System)
Organization: Technical University of Munich, Germany
References: <w=[e-mail]> <[e-mail]>  <jburney.714920310@seamis1> <[e-mail]> <[e-mail]>
Date: Wed, 9 Sep 1992 07:59:04 GMT
Lines: 43

<[e-mail]> writes:

>...
>  Before you scoff at that 8K cache, it is NOT DIRECT MAPPED, WRITE THROUGH!
>That Intel cache is a 4-way set associative, write back cache and is

According to Intel literature the onchip-cache is 4-way write through.
Simulations have shown, that at full bus speed (achievable by an
external cache) the write-through approach is even a small bit faster
than a write-back cache.

>roughly equivalent to the 64K external caches of most Motherboards!  Of
>course, a 128K, 2-way... cache is roughly equivalent to the 256K systems
>of many current motherboards.  You can not judge a cache by size alone.

In fact you cannot judge it by size alone. And you cannot judge it by
associativity and size alone. Just what about line size, for example.
To my (limited) experience line size and cycles needed to refill a line
(can execution start before line is filled or must the CPU wait) is
much more important as associativity. Frankly I don't dare to give
any formula that holds for any application to give cache performance.

The big gain of the internal cache comes from fast communication on the
chip. No external cache of any size can achieve this. And if the internal
cache can achieve a 90% hit-rate, there is not that much room for further
improvement by external caches.

>...
>   Fevrier - Replace your crystal (50 or 100 MHz) with a 40 or 80 MHz
>one.  Your CPU will be slower than at 50MHz but faster than 33 MHz and
>the added 5nS per cycle will make that cache zero wait state.  Save the
>original crystal for when you upgrade the cache to < 20 nS!

This amazes me. I thought, the number of waitstates is hardwired into
some state machine that simply "knows" that the memory will deliver data
within the n-th cycle. Of course, if you slow down the clock or buy
faster RAMs the data will eventually be valid one cycle earlier. But how
does the system distinguish valid data from invalid data? That is, how
is it supposed to eliminate one wait state without beeing told so?

>    Jeff Andle

Michael Hermann