Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rice!uw-beaver!zephyr.ens.tek.com!orca.wv.tek.com!leia!opus!johnt
From: johnt@opus.WV.TEK.COM (John Theus;685-2564;61-183;625-6654;hammer)
Newsgroups: comp.arch
Subject: Re: _really_ ciscy (Futurebus+)
Keywords: Futurebus
Message-ID: <276@leia.WV.TEK.COM>
Date: 19 Dec 89 06:59:40 GMT
References: <7172@pt.cs.cmu.edu> <112400007@uxa.cso.uiuc.edu> <390@blenheim.nsc.com> <411@blenheim.nsc.com> <1328@atha.AthabascaU.CA>
Sender: johnt@leia.WV.TEK.COM
Reply-To: johnt@opus.WV.TEK.COM (John Theus)
Organization: Tektronix, Inc., Wilsonville, OR
Lines: 23

In article <1328@atha.AthabascaU.CA> rwa@cs.AthabascaU.CA (Ross Alexander) writes:
>des@dtg.nsc.com (Desmond Young) writes:
>
>>Anyway, if you want to go fast, it has too much baggage.
>>My Opinion etc.
>
>   Agreed.

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

As I stated in a previous posting, we expect to be building Futurebus+
hardware in the coming year that can sustain 500 Mbytes/sec on a 64 bit
wide data path.  The questions that immediately come to mind are either
this does meet your definition for "fast", or you don't believe we can
deliver this bandwidth.

Some background for your comments would be helpful.  Thanks.

John Theus					johnt@opus.wv.tek.com
Futurebus+ Parallel Protocol Coordinator
Tektronix, Inc.
Interactive Technologies Div. - shipping the Futurebus-based XD88 workstations