rwa@cs.AthabascaU.CA (Ross Alexander) (12/19/89)
des@dtg.nsc.com (Desmond Young) writes: > This does hint at the very (very) CISC nature of Futurebus+. It has >every facility (almost) ever dreamt of. As an analogy to CISC >processors, it almost has a single instruction to compile a program :-). Now hold on a minute, didn't the Fairchild SYMBOL machine have a single instruction that would do a compile (in a random hardware implementation, as I remember). It was a pretty ugly language grammatically but the compilations just blazed through. > (Well, a wee bit of an exaggeration). Hell no. I'm serious. >Anyway, if you want to go fast, it has too much baggage. >My Opinion etc. Agreed. -- rwa@aungbad.AthabascaU.CA Ross Alexander (403) 675 6311
johnt@opus.WV.TEK.COM (John Theus;685-2564;61-183;625-6654;hammer) (12/19/89)
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
stevew@wyse.wyse.com (Steve Wilson xttemp dept303) (12/20/89)
In article <1328@atha.AthabascaU.CA> rwa@cs.AthabascaU.CA (Ross Alexander) writes: >des@dtg.nsc.com (Desmond Young) writes: >> This does hint at the very (very) CISC nature of Futurebus+. It has >>every facility (almost) ever dreamt of. As an analogy to CISC >>processors, it almost has a single instruction to compile a program :-). > > Now hold on a minute, didn't the Fairchild SYMBOL machine have a >single instruction that would do a compile (in a random hardware >implementation, as I remember). It was a pretty ugly language >grammatically but the compilations just blazed through. This is a non-sequitor to the entire thread! Des was trying to come up with an analogy between CISC and a bus standard. The fact that the SYMBOL box might have had an instruction to do this has no real connection. Along this line maybe its time for some new acronyms to describe a Complicated Standard Bus (CSB?) or a Simple Standard Bus (SSB - no wait - that stands for Single Side Band...) I know, how about Easy Standard Bus (ESB). Anyone have any better suggestions? Steve Wilson
stevew@wyse.wyse.com (Steve Wilson xttemp dept303) (12/20/89)
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.
lamaster@ames.arc.nasa.gov (Hugh LaMaster) (12/20/89)
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