mmm@cup.portal.com (Mark Robert Thorson) (12/10/90)
What are the likely successors to VME, and why? How is the role of the bus in computer architecture likely to change? How significant will Futurebus+ become? It strikes me that "Futurebus" is about the worst name that the IEEE committee could have chosen. Their goal is an architectural definition which will live through several incarnations of implementation technology. 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. But much worse is PR image it creates -- the image that "Futurebus" is a bus in the sense of more familiar buses like Multibus, VME, etc. It is an architecture for a network of processors, memory, caches, bus repeaters, etc. It is a certain type of model, in which everybody sees the same memory space, with cache coherency maintained in hardware. It seems like a very general model, one which can be viewed as a superset of more restricted models such as those which do not provide cache coherency, and yet one which should have an implementation cost competitive with that of the more restricted models. At the same time, it imposes very few restrictions on the network architecture. You can't have loops or redundant paths, but other than that the network organization is arbitrary. So what does comp.arch think? Is Futurebus+ a model which can serve all of our needs for the next 10-20 years? Or is the model inappropriate for what we'll be doing with buses in the future (i.e. will the role of the bus change)? Or am I asking the wrong questions -- what are the right questions when trying to predict the future of buses?
aglew@crhc.uiuc.edu (Andy Glew) (12/10/90)
Well, I'm going to be deliberately antagonistic here. I'm not as
opposed to FEATUREbus+ as I appear to be here. In fact, I voted for
acceptance of the standard - because the standard has been far too
blooming long in coming.
What are the likely successors to VME, and why? How is the role of
the bus in computer architecture likely to change? How significant
will Futurebus+ become?
The likely successor to VME is VME-64. It's simple, fast, and
available now. The likely successor to VME-64, if there is a lineal
successor, will probably involve noticing that there are extra pins on
most VME boards second connector...
FUTUREbus+'s impact will be as an I/O bus -- the profile that DEC is
pushing. The processor to memory connection is too important to be
left a standard bus, especially a standard bus that is as featureful
as FUTUREbus.
--
Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]mark@mips.COM (Mark G. Johnson) (12/10/90)
I have a complaint about Futurebus: if you want to build a really high
clockrate bus, they specified a less-than-optimum connector, DuPont's
"Metral". Metral has several nifty features, including modularity (you
can get Metral modules for high curent power connections, coaxial cables,
fiber optics, etc etc), higher density: 2.0 mm pitch instead of 2.54mm,
and low cost.
On the downside, the parasitic inductance and capacitance of Metral is
very high, which limits its applicability in very high speed (sub 15ns)
backplanes. Worse yet, Futurebus is "single ended" (N data bits are sent
over N wires) instead of "differential" (N databits sent over 2N wires),
so Futurebus has lots of signal-to-signal interaction, known in the
business as "crosstalk". The Metral connector exacerbates this problem
because Metral's 2mm pitch causes large amounts of coupling --> high
crosstalk. From the standopoint of parasitic inductance and capacitance,
MUCH better connectors are available; for example, the *worst* pin in
the RC6280's backplane bus connector has far _less_ L and C than the
*best* pin in the Metral.
Seemingly the Futurebus committee has decided that higher performance
connectors are desirable; word is out that a new revision of the
Futurebus spec will permit two other, mechanically incompatible,
connectors in addition to Metral..... and these two other connectors
have much lower L, C, and crosstalk. Pretty appealing, no?
--
-- Mark Johnson
MIPS Computer Systems, 930 E. Arques M/S 2-02, Sunnyvale, CA 94086
(408) 524-8308 mark@mips.com {or ...!decwrl!mips!mark}henry@zoo.toronto.edu (Henry Spencer) (12/11/90)
In article <AGLEW.90Dec9184818@lasso.crhc.uiuc.edu> aglew@crhc.uiuc.edu (Andy Glew) writes: >... The processor to memory connection is too important to be >left a standard bus, especially a standard bus that is as featureful >as FUTUREbus. This last deserves further attention, I think. My belief is that buses have hit about the point that processor architectures were at a decade or so ago: drowning in their own useless complexity. FUTUREbus is the Intel 432 of buses. I eagerly await the RISC revolution. -- "The average pointer, statistically, |Henry Spencer at U of Toronto Zoology points somewhere in X." -Hugh Redelmeier| henry@zoo.toronto.edu utzoo!henry
pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/11/90)
On 10 Dec 90 18:53:46 GMT, henry@zoo.toronto.edu (Henry Spencer) said: In article <1990Dec10.185346.4114@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: henry> In article <AGLEW.90Dec9184818@lasso.crhc.uiuc.edu> henry> aglew@crhc.uiuc.edu (Andy Glew) writes: aglew> ... The processor to memory connection is too important to be aglew> left a standard bus, especially a standard bus that is as aglew> featureful as FUTUREbus. henry> This last deserves further attention, I think. My belief is that henry> buses have hit about the point that processor architectures were henry> at a decade or so ago: drowning in their own useless complexity. henry> FUTUREbus is the Intel 432 of buses. I eagerly await the RISC henry> revolution. Hasn't it already happened and nobody noticed? But NUbus has so far not been incredibly popular, which is a real pity. Apple more or less killed it by adopting it in a nonstandard version (strange form factor mostly). Just look at the sort of very alluring systems TI managed to build around it as a proof of what can be otherwise done. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
sritacco@hpdmd48.boi.hp.com (Steve Ritacco) (12/12/90)
I thought that the only reason for standard buses is to necessitate proprietary ones. Have my cynical hat on today. Of course this is not my employer's oppinion, it's not even mine!
jack@cwi.nl (Jack Jansen) (12/12/90)
henry@zoo.toronto.edu (Henry Spencer) writes: >... My belief is that buses >have hit about the point that processor architectures were at a decade or >so ago: drowning in their own useless complexity. FUTUREbus is the >Intel 432 of buses. I eagerly await the RISC revolution. I have the strong feeling that Futurebus will never take off, except maybe for some niche market. VME took about 5 years to take off (i.e. before more than 10 firms started making boards for it). Multibus II (about an order of magnitude more complex) never took off, and will now probably die slowly with Intel so involved in Futurebus. MB-II was already too complex for most applications except for some very specialised things. Futurebus is worse, and quite a bit later as well. I think that FDDI and VME will have divided the low and middle end of Futurebus' market by the time it comes available. That would leave only the very high performance multi-processor market (flightsimulator and such). Not really a market that will have hundreds of vendors build boards for it.... -- -- Een volk dat voor tirannen zwicht | Oral: Jack Jansen zal meer dan lijf en goed verliezen | Internet: jack@cwi.nl dan dooft het licht | Uucp: hp4nl!cwi.nl!jack
lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) (12/12/90)
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. I agree with this statement. Like "Modern" architecture, it will seem dated before long. But, 30 years? That is a very optimistic. I suspect the name will seem an anachronism in the year 2000 at best. Some suggest it is already an anachronism. >But much worse is PR image it creates -- the image that "Futurebus" is a >bus in the sense of more familiar buses like Multibus, VME, etc. I think this is probably how it will turn out, however, because it isn't clear at all that the architecture it defines will be long useful for anything more than that. There does seem to be a lot of interest in Futurebus+ as an I/O bus, and I expect it to be, in fact, a good I/O bus. >So what does comp.arch think? Is Futurebus+ a model which can serve all >of our needs for the next 10-20 years? Or is the model inappropriate for >what we'll be doing with buses in the future (i.e. will the role of the >bus change)? Or am I asking the wrong questions -- what are the right >questions when trying to predict the future of buses? Is the architecture which Futurebus+ supports able to be used to build a 8 processor shared memory machine with each processor 45-270 SPECmarks? {360-2160 "total SPECmarks"}. Consider this: A number of companies are now developing BiCMOS which will run in the 90-210MHz range, with 750,000+ transistors. {Reference: Electronics Magazine, Dec 1990} This is enough for a basic SPARC integer CPU with a small on-chip cache, by my reckoning. Just an an example. Make your own back-of-the-envelope calculations and see what you come up with :-) If you consider SPECmark/MHz ratios of todays RISC CPUs (.5-1.3) (roughly, SPARC-I to IBM RS/6000), 45 SPECmarks is the *minimum* speed you are likely to see in the next generation of chips, with 90 SPECmarks common, and up to 270 likely by 1995 at the high end. This gives a range of 360-2160 total system SPECmarks which must be fed by the memory subsystem on an eight processor system. BTW, this is based purely on public information printed in trade journals, with simple arithmetic applied. An eight processor system of such CPUs is likely to need .4-50 Gbytes/sec of processor-memory bandwidth, depending on floating point speed, cache speed and size, and other system considerations. (This figure arrived at by looking at the internal bus speeds of various DEC, Sun, and SGI systems common today, and the Cray Y-MP.) {For reference, the Cray Y-MP runs at 166+ MHz, and has a processor-memory bandwidth of 40+ GBytes/sec on an 8 processor system.} 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. 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. This assumes that a general purpose bus is still desirable for disk I/O. The SBus, Turbochannel, and HiPPI approach is for a "channel" like bus with an interface to the processor, with a variety of possible interface methods at the CPU side, depending on how many such channels need to be interfaced to the CPU-memory bus. DEC claims that Turbochannel interfaces will be very cheap to build, and should be much cheaper than Futurebus+. Maybe SBus and Turbochannel should be standards... Put another way, why *should* future systems support a general purpose memory-mapped bus architecture at all? Logic is cheap now. 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 Cray IOPs going to HSX/HiPPI channels, etc. Only a lot cheaper. With SBus, Turbochannel, and HiPPI interfaces, perhaps, as the available options. 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. Naturally, this is my opinion only and does not reflect the opinions of NASA or the U.S. Government. Hugh LaMaster, M/S 233-9, UUCP: ames!lamaster NASA Ames Research Center Internet: lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 With Good Mailer: lamaster@george.arc.nasa.gov Phone: 415/604-6117
cbo@hprnd.rose.hp.com (Calvin Olsen) (12/13/90)
In comp.arch, mark@mips.COM (Mark G. Johnson) writes:
I have a complaint about Futurebus: if you want to build a really high
clockrate bus, they specified a less-than-optimum connector, DuPont's
"Metral".
A Futurebus+ claim to fame is: technology independent logical protocols.
Your mileage certainly does vary, depending on implementation choices.
On the downside, the parasitic inductance and capacitance of Metral is
very high, which limits its applicability in very high speed (sub 15ns)
backplanes.... From the standpoint of parasitic inductance and capacitance,
MUCH better connectors are available; for example, the *worst* pin in
the RC6280's backplane bus connector has far _less_ L and C than the
*best* pin in the Metral.
Unquestionably, there are better connectors (electrically and otherwise).
Given that the limitations to performance in the Futurebus protocols are
primarily physics limitations, and assuming that implementations are stumbling
across the connector as THE high bar on the pareto of limitations for MOST
applications, the connector choice might be reconsidered. To date, the
Fb+ working group members have yet to be convinced that the connector itself
is currently or will be in the near future the primary cause for implementation
concern. I'm not trying to defend the Metral design, but we're talking
products and marketing here.
Seemingly the Futurebus committee has decided that higher performance
connectors are desirable; word is out that a new revision of the
Futurebus spec will permit two other, mechanically incompatible,
connectors in addition to Metral..... and these two other connectors
have much lower L, C, and crosstalk. Pretty appealing, no?
Within the physical portion of the standard (896.2), "profiles" may specify
any connector. To date, however, most commercially-driven profiles (A/B/F)
have specified the Metral design, at least publically. Profile D, the
"desktop" (EISA) form factor, could actually deliver better performance than
the Metral, and at significantly lower cost. Certainly other connector
schemes could do as well or better. As always, weighing the cost vs net
performance benefit for a given application/market is necessary.
--
-- Mark Johnson
MIPS Computer Systems, 930 E. Arques M/S 2-02, Sunnyvale, CA 94086
(408) 524-8308 mark@mips.com {or ...!decwrl!mips!mark}
Calvin Olsen
(not speaking on bahalf of) Hewlett Packard
cbo@hprnd.rose.hp.com (916) 785-4291shri@ncst.ernet.in (H.Shrikumar) (12/13/90)
In article <AGLEW.90Dec9184818@lasso.crhc.uiuc.edu> aglew@crhc.uiuc.edu (Andy Glew) writes: > >The likely successor to VME is VME-64. It's simple, fast, and >available now. The likely successor to VME-64, if there is a lineal >successor, will probably involve noticing that there are extra pins on >most VME boards second connector... I was under the (evidently wrong) impression that VME-64 uses those pins! Could you drop in a brief note on the pinout please ? >FUTUREbus+'s impact will be as an I/O bus -- the profile that DEC is >pushing. The processor to memory connection is too important to be >left a standard bus, especially a standard bus that is as featureful >as FUTUREbus. (Aside: Thats funny, not very long ago when I was involved in the design of a multi-proc UNIX box (the HCL Magnum, 6x68030), we had a future-bus-like bus for the system memory access (which used those very unused pins :-), and VME-32 for I/O. The other way around!) So will all FutureBus's support for cache coherency go waste, and need to be reinvented in the "proprietary" system bus ? A pity! Do you mean ... "A standard is a formal statement of obsolesence." ? Or I think ... Looks to me, is all just a big orchestration by the manufacturers to sell more memory boards at prices they can fix ! ("No third party memory!") #1. How would high density DRAM affect design ? Will the coming of even-higher-density DRAMS see more movement of memory onto the CPU boards so that the "system bus" collapses into a bunch of PCB traces ? Then the only backplane will be for I/O, and (relatively low granularity) memory caching/sharing, both of which FutureBus is good for. #2 How would High Speed Networking affect design ? If one watches the high-speed protocol people, such as people at Uwash, St. Louis, MO, they are worrying about how to handle the guzzling I/O rates of Gigabit networking. And most solutions tend to split memory into several units, each with a high speed interface (sort of like the video-RAM chips, only these are multi-chip boards). And the most general backplane interconnect is a cross-point like one. this would alter the picture considerably, since the each board has lots of memory AND I/O, the backplane then carries only a small fraction of the load. So, will the coming of >64Mb dram+~1Gbps networking deemphasise the bus to a mere shared-semaphore-resolver ? Will Future Bus kick off in that context ? Is that what DEC has in mind (unlikely) ? May those great trapezoidal bus drivers at least survive! One thing seems likely to me, better analysis of the bus-dynamics, such as the FutureBus has done and as all ECL-nsec-squuezers always do, will be a must in future backplane designs. Thats one major first in that FutureBus, so there is future in that technology surely! BTW, how does the equiv of the bus in (for eg.) in a Y-MP compare with the FutureBus - in the departments of cache-coherence, bus-collisions/requests and raw I/O rate ? #3. Are #1 and #2 really valid ? Will all future machines have lots of memory on board ? Looks like an obvious yes to me. Will all future machines want to do High Speed I/O ? Maybe not, but design is likely to be influenced in that direction. Makes sense to put memory, CPU and I/O in one board, if density allows. How far are we looking into the future ? And how foggy is my crystal ball ? >-- >Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi] -- shrikumar ( shri@ncst.in )
mo@messy.bellcore.com (Michael O'Dell) (12/13/90)
Very fast computers don't have busses. They do everything the hard way: very fast point-to-point interconnects. Yes, the multiport memory controller on such machine is *quite* complex. -Mike
colwell@omews54.intel.com (Robert Colwell) (12/14/90)
In article <1990Dec13.153204.3294@bellcore.bellcore.com> mo@messy.UUCP (Michael O'Dell) writes: >Very fast computers don't have busses. They do everything the >hard way: very fast point-to-point interconnects. > >Yes, the multiport memory controller on such machine is *quite* complex. Mike is quite right. The last machine we designed at Multiflow had a 15 nS cycle time, and it was no picnic even to get off one gate array, traverse a few inches of PC board, and make setup on the input flop to another. Getting across a backplane was much harder. To get enough connectivity we used high density connectors, but then crosstalk (with these very fast edges) can become a problem. And the connectors exhibit considerable impedance changes vis a vis the etch on the board or the backplane, not to mention their capacitance. The overall effect was that the gate array pins themselves were 3 unit loads, the backplane connectors were 3 loads each (and each signal saw at least two of them) and the destination array exhibited 3 loads. There are better impedance-controlled connectors coming out now using flexstrips and the like, but their reliability and longevity has yet to be proven, they're quite expensive, and they're largely single-sourced. Essentially, all important backplane buses had to be single-source, single-dest, driven by 50 ohm drivers, properly terminated at the destination. So is this any longer a bus, or just a collection of wires that share a common name? Bob Colwell mipon2!colwell@intel.com 503-696-4550 Intel Corp. JF1-19 5200 NE Elam Young Parkway Hillsboro, Oregon 97124
lindsay@gandalf.cs.cmu.edu (Donald Lindsay) (12/14/90)
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
minich@d.cs.okstate.edu (Robert Minich) (12/14/90)
> ... But NUbus has so far not > been incredibly popular, which is a real pity. Apple more or less killed > it by adopting it in a nonstandard version (strange form factor mostly). Hmm, I recall that Apple got this form factor included in the standard. I also recall that the other form factor is not very conducive to desktop machines unless you have a big desk top. Doesn't the NeXT use the larger form factor? -- |_ /| | Robert Minich | |\'o.O' | Oklahoma State University| "I'm a newcomer here, but does the |=(___)= | minich@d.cs.okstate.edu | net every lay any argument to rest?" | U | - Ackphtth | -- dan herrick
phil@brahms.amd.com (Phil Ngai) (12/15/90)
In article <1990Dec14.003959.16647@d.cs.okstate.edu> minich@d.cs.okstate.edu (Robert Minich) writes: |I also recall that the other form factor is not very conducive to desktop |machines unless you have a big desk top. Doesn't the NeXT use the larger |form factor? Speaking of form factors and Next, it seems absurd that they are proud of having a thin "pizza" box and then need a stand to raise their CRT to eye level. Looks sexy, but functionally it would be better to just have a thick box and put the CRT on it directly. --
shri@ncst.ernet.in (H.Shrikumar) (12/20/90)
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 )
iyengar@grad2.cis.upenn.edu (Anand Iyengar) (12/21/90)
In article <1200@shakti.ncst.ernet.in> shri@ncst.ernet.in (H.Shrikumar ) writes: > 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. Interesting. If I don't mis-understand, the basic topology a mesh (before wrapping)? How does the program decide which nodes to propagate to (and on a related note, is explicit message passing used, or is there global memory addressing)? Is a toroidal wrapping any more useful? Anand. -- "The nearer your destination, the more you're slip-sliding away..." iyengar@grad1.cis.upenn.edu, iyengar@eniac.seas.upenn.edu --- Lbh guvax znlor vg'yy ybbx orggre ebg-guvegrrarg? --- Disclaimer: It's a forgery.
jps@dworkin.wustl.edu (James Sterbenz) (12/22/90)
In article <1200@shakti.ncst.ernet.in> shri@ncst.ernet.in (H.Shrikumar ) writes: >In article <1990Dec12.022537.17461@news.arc.nasa.gov> > lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes: >>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. Unfortunately, it seems as though much of the research community is doing Unix on micros using busses, and has forgotten much of the architecture and operating systems work from as far back as the mid-60's. As micros grow up to be as powerful as mainframes and supercomputers used to be, and as Unix has to grow up to be a real operating system, it makes sense to look at some of the problems that have long been solved and implemented. I'm already putting on the Asbestos suit... -- James Sterbenz Computer and Communications Research Center Washington University in St. Louis +1 314 726 4203 INTERNET: jps@wucs1.wustl.edu 128.252.123.12 UUCP: wucs1!jps@uunet.uu.net
mmm@cup.portal.com (Mark Robert Thorson) (01/14/91)
In the earlier discussion of Futurebus+, the consensus seemed to be that the model supported by Futurebus+ (i.e. processors and memory connected by a bus or a network of buses and bus repeaters) is not an interesting model because processors will be connected to memory via proprietary on-board buses. Standard buses will be used for talking to high-bandwidth peripherals, and for these purposes the features of Futurebus+ are overkill. So what is the argument for Futurebus+? Do its designers anticipate future low silicon costs will make the cost of implementing Futurebus+ an imperceptible drop in the bit bucket? Or is there some other technological development, such as multithreaded operating systems, which will make the Futurebus+ model popular? Will standard buses evolve toward simpler interfaces, more appropriate for mass I/O? Or will the CPU bus evolve into something like (or exactly like) Futurebus+? Or will standard buses get replaced by something else, like dedicated buses?
rpw3@rigden.wpd.sgi.com (Rob Warnock) (01/14/91)
In article <38005@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes [with significant editing by me]: +--------------- | ... Standard buses will be used for talking to high-bandwidth peripherals, | and for these purposes the features of Futurebus+ are overkill. | So what is the argument for Futurebus+? ... Or is there some other | technological development... which will make the Futurebus+ model popular? +--------------- The first thing that comes to my mind is that no existing standard bus has the capacity to handle the "high-bandwidth peripherals" of tomorrow, and even Futurebus+ may not be "overkill". Consider HiPPI (100 or 200 Mbyte/sec), SONET (up to 3 Gbit/s), live video, and things we haven't thought of yet. If the very notion of "third-party vendors" is to survive, we are going to need a new "standard" place for their products to plug in. (No, I don't believe every presently existing PC peripheral had been anticipated by the time the PC bus design was frozen.) -Rob ----- Rob Warnock, MS-9U/515 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311