Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!lll-winken!ames!ames.arc.nasa.gov!lamaster
From: lamaster@ames.arc.nasa.gov (Hugh LaMaster)
Newsgroups: comp.arch
Subject: Re: Future Bus
Keywords: Future Bus Standard, VMEbus, RISC, FUTUREbus+
Message-ID: <37873@ames.arc.nasa.gov>
Date: 11 Dec 89 20:45:21 GMT
References: <2913@trantor.harris-atd.com> <391@blenheim.nsc.com>
Sender: usenet@ames.arc.nasa.gov
Distribution: comp.arch
Organization: NASA - Ames Research Center
Lines: 29

In article <390@blenheim.nsc.com> dave@dtg.nsc.com (David Hawley) writes:
>>

Futurebus seems to address many problems, and, I recall that
the bus driver logic is supposed to be the greatest thing since Velveeta.

On the other hand, someone remarked that: 

"I am particularly concerned about the arbitration protocols - they
seem destined to be slow and complicated."

Is it too late to do anything about the the arbitration problem?  Since the
bus appears to be extremely good in many ways for, I
would hate to see an Achilles heel sneak in.  

Some previous posters questioned whether the world needed FUTUREbus,
since many systems will use faster, cheaper, simpler, (and proprietary!) 
private memory buses.  I believe that it is needed.  A single disk
controller card can now saturate a VMEbus, even as an I/O device.  See
Xylogics' new IPI-2 card, for example.  I believe that vendors are
going to "discover" a tremendous demand for higher performance I/O once
the industry standard is there to support it.  VMEbus is great, but two
years from now I bet people are going to be wondering how they ever got along
with only ~20MB of I/O bandwidth. 

  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