Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!udel!rochester!pt.cs.cmu.edu!gandalf.cs.cmu.edu!lindsay
From: lindsay@gandalf.cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: The Future of Buses (and Futurebus)
Message-ID: <11391@pt.cs.cmu.edu>
Date: 13 Dec 90 23:18:13 GMT
References: <36734@cup.portal.com> <1990Dec12.022537.17461@news.arc.nasa.gov>
Organization: Carnegie-Mellon University, CS/RI
Lines: 46

In article <1990Dec12.022537.17461@news.arc.nasa.gov> 
	lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes:
>In article <36734@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes:
>>Should they succeed, the name "Futurebus" will seem as anachronistic in 30
>>years as the name "Futuretran" or "Futurebol" would seem today, had it
>>been applied to Fortran or Cobol.

The "N" in nroff - about the oldest word processing package still
available - stands for "new". To anyone who remembers "runoff", that
it was newer than: there is a nostalgia newsgroup, and this isn't
it...  I would also point out New College, which was added to Oxford
University in 1379.

>My question, for those who expect Futurebus+ to become a CPU-memory bus, is,
>Can Futurebus+ support data rates of .4-50 GBytes/sec?  Because, that is what
>will be needed.  From what I hear, you might expect 50-200 MBytes/sec,
>depending on a lot of things, and which model you choose.

The literature talks about packet mode running at up to 100 mega-
transfers per second, with two overhead transfers per packet.
However, not all boards will have high-speed capability, and systems
with long, heavily loaded backplanes will run more slowly. So,
pessimists should apply some scaling factor - 2 or 3 or so. The data
width spec lists at least 32, 64, and 128: I'm not sure about 256.

A packet can be 64 transfers (+2), but let's take a small cache line
(16 bytes) on a narrow, slow implementation (30 MHz???).  This takes
6 transfers, so it can be repeated at 5 MHz, for a peak rate of 80
MB/s.

A big packet, at full rate, 128 bits wide, is 16 bytes * 100 MT/s =
1.6 GB/s (less 2/64 overhead). Double that again if you believe in
big connectors, but I'm afraid your 50 GB/s is out of the question.

>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?

The trouble with "cheap" is that interleaving is pin-intensive, with
relatively little logic per pin. I recall a Stardent memory board
(Titan I?) which spent about half the board in the multiport/
interleave support: and that was with big ASICs that they were proud
of.

-- 
Don		D.C.Lindsay .. temporarily at Carnegie Mellon