Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!sdd.hp.com!mips!mash From: mash@mips.com (John Mashey) Newsgroups: comp.arch Subject: Re: ACE, buses, and the future of ultrix Message-ID: <3942@spim.mips.COM> Date: 28 May 91 05:09:34 GMT References: <816@cadlab.sublink.ORG> <3683@spim.mips.COM> <864@cadlab.sublink.ORG> Sender: news@mips.COM Organization: MIPS Computer Systems, Inc. Lines: 136 Nntp-Posting-Host: winchester.mips.com In article <864@cadlab.sublink.ORG> martelli@cadlab.sublink.ORG (Alex Martelli) writes: >mash@mips.com (John Mashey) writes: >:In article <816@cadlab.sublink.ORG> martelli@cadlab.sublink.ORG (Alex Martelli) writes: >:> ... > ... >:>Don't forget they'll support BOTH Dec Turbochannel AND EISA... so, times >:>two again... the bus variation may be the most important of the three, for >:>3rd party addon-board manufacturers, and for purchasers of vast numbers of >:>machines, who can't really buy machines with different buses if they want >:>to be able to minimize spare parts inventory for the addon cards. >: >:This is nonsense. > >Thanks, very diplomatic of you. Have you read what you quoted? I opined that >the bus variation can be more important than the variation in operating >systems and in CPUs (R3000's vs R4000's) for two classes of companies: >manufacturers of add-on cards, and purchasers of many machines, who want >bus uniformity for spare-parts inventory. I'll explain later why I said "nonsense", which was to the general thrust of the argument leading up to and including this, not that many people wouldn't prefer there be exactly one of any choice, as long as that choice was goodenough for them. This was less diplomatic than usual and I apologize for that. Clearly, some 3rd-party vendors care (although a lot of board vendors supply drivers, so they care a fair amount about the software end also.) For various reasons, many third-party vendors will not do both boards. 1) Some will decide TC wouldn't have enough volume. 2) Some will decide that what they do needs the TC performance, and won't do EISA. Likewise, people who buy vast numbers of machines .... would prefer to buy exactly the same configuration ... if that makes sense. Would you agree that the overall sense of your posting was that, among other things, it was dumb to have two busses? and, that it was a Big Deal that we did this Dumb Thing? (If not, then I retract the "nonsense" claim). If your posting generally meant the comment above, I observe: 1) In the current situation, we've already got, at least XT bus AT bus {EISA, MCA, VME, and S-bus, Nu-bus} TurboChannel and in fact, if somebody has both {AT and MCA}, they already have the problem. If they have {AT, and EISA}, they have the problem if the EISA-bus machines need higher-performance cards that won't work in the AT-bus. At least this effort didn't add any newly-created busses, and it picked two that have relevantly different performance characteristics. (TC has a peak performance 3X that of EISA; sustained throughput 2-3X, which is relevant to some of us.) 2) It is nice to believe that "one size fits all", but this is ABSOLUTE FANTASY, in the performance domain into which personal systems are moving into in the next couple years. >You seem to be answering, and deeming 'nonsense', some different assertion, >one which I did not make...: Again, if I mis-read the sense of the posting, culminating in that section, then I'm sorry. However, the whole direction of the posting seemed to be driven without the understanding of the reasoning behind doing it. >Sure, it's evil for application software to know about bus structure, and >sure, it's nice for the kernel to be able to ignore it, too, but what does >this have to do with my assertion being 'nonsense'? It makes life easier >for writers of software, and for purchasers of same, but does not remove >the misery from manufacturers and purchasers of add-on cards... if the ACE >consortium had blessed ONE bus, instead of two, it would have something >more 'standard' in its hands, just as if it had blessed one OS, rather than >one and one half. Like I said, there are some pretty good technical reasons for this. EISA was stretched pretty far to retain all of the old compatibility. >Incidentally, the XT->AT->EISA bus evolution is a possible solution, although >not necessarily optimal; another one is to standardize just an 'EXTERNAL' bus, >for add-ons, whose performance may be acceptable even on an 'old' bus, while >keeping implementor freedom for internal structures (the EISA in an HP/700, >like the VME in a Soulbourne or the Sbus in an SS2, is not really slowing >down the machine, is it? Besides, look at what Soulbourne is doing - if >the 25 Mbytes/sec total throughput of VME is stunting your growths, just >put in *multiple* VME 'buses', on separate "I/O channel boards"). (Now, after this, I stand behind "nonsense".) We already ship machines with multiple (up to 6) VME busses, in RC6280 (about 50-mips). This is fine for big servers whose goal is connectivity, and hence multiple medium-speed channels are OK, but it doesn't increase the maximum bandwidth. and it's got way too many chips to put in a small-box desktop. Note that 50+-mips desktops are appearing rapidly, and by 1992 are certainly going to get under $10K, from multiple vendors. (Note that the Solbourne and SS2 CPUs (40MHz SPARCs) are approximately 20+-mips on this scale.) For some things that you might want to build, an EISA-bus is perfectly appropriate, but it just simply doesn't have the overall performance and peak bandwidth necessary to build some of the things that people want to build, at reasonable cost. For some uses, the busses you mention aren't slowing them down ... but for some others, I'm sure they're a bottleneck. (This is not to say they're bad designs; sometimes you build something with a lot of CPU power, and less I/O than you'd like, to meet cost goals, just because it's less difficult to get the CPU power.) To summarize: 1) Any of these busses has a legitimate role in life. 2) If it's good enough, buy something cheap, with lots of boards. 3) However, observe that there needs to be some reasoanble relationship between CPU performance and I/O performance, at REASONABLE cost for the class of machine being built. 4) The desktop machines of the next few years are not adding 1-2 mips per round, they're adding 10-30, and this is going on in low-chip-count machines, which, however, besides the usual PCish sorts of peripherals, would sometimes like to have high-speed subsystems for graphics and/or networking, among other things. 5) As I've said in numerous public talks, one of the worst problems we (computer biz) has is making I/O scale up appropriately with the CPUs. It is much easier to scale up the connectivity by MUXing together existing slower busses onto a fast backplane (although it is often harder than it looks, and more talked of than done.), than it is to boost the performance of a single I/O bus that is suitable for a <$10K machine. 6) Consider that VME got started with <1mips machines, and has served well ... but wouldn't people expect it to run out of steam sooner or later? 7) Anyway, that's the bottom line: if EISA and TC occupied the same part of the design space, then people should complain that this was a committee compromise decision ... but they don't, and nobody should be surprised to see both EISA and TC products from the same vendors, for perfectly rational reasons. I would guess that you'll see EISA-based Rxxx earlier than TC-based X86 machines, but that's just a guess. It would be nice to believe one size fits all, and it would be very convenient for lots of people ... but the numbers don't work. -- -john mashey DISCLAIMER: UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems MS 1/05, 930 E. Arques, Sunnyvale, CA 94088-3650