Path: utzoo!attcan!uunet!snorkelwacker.mit.edu!apple!usc!elroy.jpl.nasa.gov!ames!pioneer.arc.nasa.gov!lamaster From: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) Newsgroups: comp.arch Subject: Re: The Future of Buses (and Futurebus) Message-ID: <1990Dec12.022537.17461@news.arc.nasa.gov> Date: 12 Dec 90 02:25:37 GMT References: <36734@cup.portal.com> Sender: usenet@news.arc.nasa.gov (USENET Administration) Reply-To: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) Organization: NASA Ames Res. Ctr., Mtn Vw CA 94035 Lines: 98 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