Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC840302); site boring.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!mcnc!philabs!cmcl2!seismo!mcvax!boring!jack
From: jack@boring.UUCP
Newsgroups: net.micro.16k
Subject: Re: 32xxx bus cycles & CPU speed(& cache)
Message-ID: <6365@boring.UUCP>
Date: Fri, 22-Mar-85 13:59:58 EST
Article-I.D.: boring.6365
Posted: Fri Mar 22 13:59:58 1985
Date-Received: Tue, 26-Mar-85 05:29:14 EST
References: <928@sjuvax.UUCP> <446@terak.UUCP> <971@sjuvax.UUCP>
Reply-To: jack@boring.UUCP (Jack Jansen)
Organization: CWI, Amsterdam
Lines: 24
Summary: 
Apparently-To: rnews@mcvax.LOCAL


Hey, come on! The days that cache was used because memory
was slow lay years behind us.
CACHE IS USED SO THAT THE PROCESSOR KEEPS ITS GRABBING HANDS
OFF THE BUS!!
If you have a system wich is more or less balanced in it's
CPU and disk usage, you gain an awful lot by adding a cache.

This will enable the CPU to continue running while the disk
controller is stuffing bytes into memory, without having to add
wait states because someone else is the bus master.

For this, your cache doesn't even have to be extremely fast.
Even if you have to let the CPU wait while you are invalidating
a cache location, this won't have too much influence on performance,
since you hardly ever look at a buffer that is currently being
filled by a disk controller, so there will be hardly any hits 
because of the disk i/o.

Of course, all these things become even more valid
when you have mulitple CPU's on one bus....
-- 
	Jack Jansen, {decvax|philabs|seismo}!mcvax!jack
It's wrong to wish on space hardware.