Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!shakti!shri
From: shri@ncst.ernet.in (H.Shrikumar)
Newsgroups: comp.arch
Subject: Re: The Future of Buses (and Futurebus)
Summary: multi-ported memory ...
Message-ID: <1200@shakti.ncst.ernet.in>
Date: 20 Dec 90 05:18:52 GMT
References: <36734@cup.portal.com> <1990Dec12.022537.17461@news.arc.nasa.gov>
Reply-To: shri@ncst.ernet.in (H.Shrikumar )
Organization: National Centre for Software Technology, Bombay, INDIA
Lines: 77

In article <1990Dec12.022537.17461@news.arc.nasa.gov> 
 lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes:
>Futurebus+ as an I/O bus, and I expect it to be, in fact, a good I/O bus.

[... because ...]

>On the other hand, disk I/O data rates of .1-2 GBytes/sec should be adequate to
>support such processors, so, Futurebus+ *might* work for I/O, depending on
>what kind of data rates you can actually get.  And how big your system is.

[...and...]

>It should be a lot cheaper to build a direct interface to the CPU-memory bus.
>I expect to see programmed I/O controllers with
>direct access to much higher throughput memory subsystems, myself.  Like

  Hmmm, this seems like an obvious consensus. 

  High functionality, dense, multi-level boards; largely self sufficient,
prop. mezzanine busses etc. to interconnect locally, hung on to a
broad-compatibility Exchange-Bus like the Future-bus.

>P.S.  On a different subject, when is someone going to come out with a cheap
>building block able to create a 10 GByte/sec 8 port interleaved memory system?
>I think that there is a world of high speed memory interconnection schemes
>dating back 25 years, anyway, that seems to be ignored by the bus-oriented
>micro industry.  Buses like Futurebus really seem to be the hard way to
>build CPU-memory connections.  I expect to see a rediscovery of memory
>interconnection ideas in the next decade as people struggle to take advantage
>of massively parallel architectures.

   Just a few days ago, the same question occured to me too, when
Prof Handler of IMMD (the German institute that works on MIMD
(interesting name for the inst :-) parallelism) was with us. He gave a
talk outlining some of their work, including the EGPA (Extensible (?)
general purpose array), and its extensions.

   EGPA had a cylinder of PEs and Memories, each memory multi-ported
onto the neighbouring processors. ie. take a fabric of alternate
PEs and MemoryElements, each PE connected to several MEs, and wrap-around
this fabric to get a cylinder. You started your program at some
convinient vertical cut along the cylinder, and the program
"data-flowed" around to successive PEs (say) clockwise.

(Aside: He also mentioned that you could take down a strip of the
cylinder for maintenance, but seems to me that with fast processors the
program would go around so fast,  ... can you replace a PE in say
10usec ? :-)

   Now the question I have has to do with reliability of multi-ports ...

It is impossible to design a "perfect" synchroniser, for multi-port
access [Buridan's Principle, Lamport]; any real synchroniser will have
a finite MTBF. Back when I was with a hardware manuf, I designed my memory
board (two ported: onto VME, and a FutureBus-like prop bus) with a
estimated 10year (30Khour) MTBF arising from the synchroniser. Slowing the
memory board increases this figure.

A quick arithmetic says that have an 8ported memory of this
design at that speed and with perhaps some 200 such in the whole
machine would give a rather bad MTBF, not too far from that of the CRAY-1.

So much for my back-of-envelope calculation, but does somebody have
figures of real machines with many multiported memories ? What sort
of MTBFs were they designed for, and how much of an impact this had
on access time ? 

It does not seem so, but was this a reason that we dont see too many
such designes around, as lamaster@pioneer.arc.nasa.gov (Hugh LaMaster)
points out ?

(I am also implicitly asserting that we are talking about "commercial
desktop" machines, where MTBFs are expected to be in the 10year range,
else you lose market to your perhaps slightly slower competitior. At least
these are the machines where standards like Future Bus are relavant.)

-- shrikumar ( shri@ncst.in )