Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!pt.cs.cmu.edu!rochester!crowl
From: crowl@cs.rochester.edu (Lawrence Crowl)
Newsgroups: comp.arch
Subject: Re: Killer Micros and the TC2000
Message-ID: <1990Mar22.221525.25734@cs.rochester.edu>
Date: 22 Mar 90 22:15:25 GMT
References: <51771@lll-winken.LLNL.GOV> <100598@convex.convex.com> <52661@lll-winken.LLNL.GOV> <798@dgis.dtic.dla.mil> <45408@ames.arc.nasa.gov> <53795@bbn.COM> <45490@ames.arc.nasa.gov>
Reply-To: crowl@cs.rochester.edu (Lawrence Crowl)
Organization: University of Rochester Computer Science Department
Lines: 16

In article <45490@ames.arc.nasa.gov>
lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes:
>My question was intentionally brief, but to be more specific: the [BBN TC
>2000 Multiprocessor] architecture obviously depends on the ability to
>parallelize in such a way that global memory bandwidth is not the bottleneck.
>How well is this working out?

My experience has been with the first Butterfly, based on the 68000.  On this
system, contention for the "inter-node" communication network was negligible.
You are far more likely to limit performance because of contention for a
specific memory module than the communication network.  I expect (but do not
know) that the same is true for the TC 2000.
-- 
  Lawrence Crowl		716-275-9499	University of Rochester
		      crowl@cs.rochester.edu	Computer Science Department
	  ...!{ames,rutgers}!rochester!crowl	Rochester, New York,  14627