Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!mips!wyse!stevew
From: stevew@wyse.wyse.com (Steve Wilson xttemp dept303)
Newsgroups: comp.arch
Subject: Re: _really_ ciscy (Futurebus+)
Keywords: Futurebus
Message-ID: <2562@wyse.wyse.com>
Date: 19 Dec 89 17:04:59 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: news@wyse.wyse.com
Reply-To: stevew@wyse.UUCP (Steve Wilson xttemp dept303)
Organization: Wyse Technology
Lines: 35

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?
>
>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.
>
>John Theus					johnt@opus.wv.tek.com

John,

I'd like to ask some questions about bus bandwidth that your experiencing
now, and how you expect this to change with Futurebus+.  

If you have a coherent system how much of the total bus tenure  is
used by the coherence handshake in a "typical" system versus total
time spent transferring data?  

How will these numbers change in the Futurebus+ system?  I'd expect
that more data will get moved due to the 64 bit path, but will 
bus tennure percentages remain about the same as the original
Futurebus?

I realize that you have to take a snapshot of some particular technology
and specific cache system to answer these questions.  I also
realize that I may be asking you some proprietary questions.  
Anything you can say will be instructional.

Steve Wilson
 
Standard Disclaimer - These are my views only, not those of my employer.