Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!uakari.primate.wisc.edu!ames!ames.arc.nasa.gov!lamaster
From: lamaster@ames.arc.nasa.gov (Hugh LaMaster)
Newsgroups: comp.arch
Subject: Re: _really_ ciscy (Futurebus+)
Keywords: Futurebus
Message-ID: <38508@ames.arc.nasa.gov>
Date: 19 Dec 89 17:14:49 GMT
References: <7172@pt.cs.cmu.edu> <112400007@uxa.cso.uiuc.edu> <390@blenheim.nsc.com> <411@blenheim.nsc.com> <1328@atha.AthabascaU.CA> <276@leia.WV.TEK.COM>
Sender: usenet@ames.arc.nasa.gov
Organization: NASA - Ames Research Center
Lines: 24

In article <276@leia.WV.TEK.COM> johnt@opus.WV.TEK.COM (John Theus) writes:

>Ok, guys, let's hear some specifics.  What is the baggage that will prevent
>Futurebus+ from going fast?  Where did we blow it?

The one word that keeps coming up wrt Futurebus+ is *Arbitration*.  I have
heard numerous times that FB+ arbitration is extremely hard for mere
mortals to understand, and will be either complicated and expensive, or,
slow, depending on implementation, *and*, that it will depend on the
slowest board in the system.

The prospect is, though, that with *reasonable cost* implementations
(being, I suppose, that it doesn't materially add to the cost of a $2500
disk controller), FutureBus+ won't be very fast (Someone said ~50MB/sec).
So, 500MB/sec is *possible*, but, some folks claim that boards capable of
this speed will be extremely expensive.  

I am repeating what I have heard, but have no independent knowledge myself.


  Hugh LaMaster, m/s 233-9,  UUCP ames!lamaster
  NASA Ames Research Center  ARPA lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035     
  Phone:  (415)694-6117