Xref: utzoo comp.arch:8752 comp.sys.intel:763
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!vette!brooks
From: brooks@vette.llnl.gov (Eugene Brooks)
Newsgroups: comp.arch,comp.sys.intel
Subject: Re: i860 Multiprocessing
Message-ID: <21876@lll-winken.LLNL.GOV>
Date: 14 Mar 89 04:10:01 GMT
References: <494@ircam.UUCP>
Sender: usenet@lll-winken.LLNL.GOV
Reply-To: brooks@maddog.llnl.gov.UUCP (Eugene Brooks)
Followup-To: comp.arch
Organization: Lawrence Livermore National Laboratory
Lines: 18

In article <494@ircam.UUCP> elind@ircam.ircam.fr (Eric Lindemann) writes:
>Does the high speed of the i860, combined with it's smallish caches, imply
>that a single processor will consume so much of the external bus bandwidth 
>that trying to put four or even two i860s on a shared memory bus would
>lead to  unacceptable performance degradation?
Yes, you would get into real trouble real quick.  You would want to have
a bus system hooked to N rather large coherent caches which the N i860s were
hooked to.  For the current part which does not have a coherence mechanism
for the on chip cache you would have to set the shared data as not cachable
as far as the on chip cache is concerned.  A good estimate of the external
cache size desired is the total main memory divided by the number of processors
you plan to configure.  If the i860 had coherence support for the on chip
cache, you would be able to implement the off chip cache with much slower
memory than otherwize, leading to cheaper and larger off chip caches.


Is the news software incompatible with your mailer too?
brooks@maddog.llnl.gov, brooks@maddog.uucp, uunet!maddog.llnl.gov!brooks