martelli@cadlab.sublink.ORG (Alex Martelli) (05/05/91)
rcd@ico.isc.com (Dick Dunn) writes (in comp.arch, re ACE): ... :for OS software that has yet to be written, why did they need to pick two :directions (times two hardware directions gives four?) instead of one? I :may be missing something important, but this aspect of ACE sure looks like :one of those "it's a dessert topping; it's a floor polish" skits. 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. I share your perplexity; and I shake my head at the rumor that Dec is going to hand over Ultrix-cum-OSF/1, lock, stock, and barrel, to SCO, to become the base of the ACEy ODT, which Dec will in turn adopt, dropping Ultrix... I hope this last rumor is wildly unfounded??? We're evaluating a centralized NFS server, and DS5500 was looking pretty good, but I would be VERY hesitant to place in such a crucial hub role in our LAN a box from a company who has just decided its system software is better manufactured by somebody else!
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (05/06/91)
In article <816@cadlab.sublink.ORG> martelli@cadlab.sublink.ORG (Alex Martelli) writes: | I share your perplexity; and I shake my head at the rumor that Dec is going | to hand over Ultrix-cum-OSF/1, lock, stock, and barrel, to SCO, to become | the base of the ACEy ODT, which Dec will in turn adopt, dropping Ultrix... | I hope this last rumor is wildly unfounded??? We're evaluating a centralized | NFS server, and DS5500 was looking pretty good, but I would be VERY hesitant | to place in such a crucial hub role in our LAN a box from a company who has | just decided its system software is better manufactured by somebody else! I think the most likely course is that SCO will start from Mach and go from there. And why shouldn't DEC have someone make their software, when they are having someone (MIPS) make their CPU? -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Most of the VAX instructions are in microcode, but halt and no-op are in hardware for efficiency"
peter@ficc.ferranti.com (peter da silva) (05/06/91)
In article <816@cadlab.sublink.ORG>, martelli@cadlab.sublink.ORG (Alex Martelli) writes: > I hope this last rumor is wildly unfounded??? We're evaluating a centralized > NFS server, and DS5500 was looking pretty good, but I would be VERY hesitant > to place in such a crucial hub role in our LAN a box from a company who has > just decided its system software is better manufactured by somebody else! Given DEC's past problems with system software, I see this as a hopeful sign. After all, you were already getting ready to buy a DEC product with a mostly third-party O/S. Why not make it explicit? -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
mjr@hussar.dco.dec.com (Marcus J. Ranum) (05/06/91)
davidsen@crdos1.crd.ge.com (bill davidsen) writes: > I think the most likely course is that SCO will start from Mach and go >from there. My understanding of the matter is that SCO will be using the OSF/1 base. The reference port for OSF/1 for the MIPS platform is the DEC port, and it's my understanding that the original SCO offering will be, basically the DEC port. It *WILL* be OSF/1 - DEC's strategy has not changed - the decision of what to *CALL* it is in SCO's hands, however, so it will most likely be sold as SCO/Open Desktop. mjr.
grr@cbmvax.commodore.com (George Robbins) (05/08/91)
In article <DV3B=4A@xds13.ferranti.com> peter@ficc.ferranti.com (peter da silva) writes: > In article <816@cadlab.sublink.ORG>, martelli@cadlab.sublink.ORG (Alex Martelli) writes: > > I hope this last rumor is wildly unfounded??? We're evaluating a centralized > > NFS server, and DS5500 was looking pretty good, but I would be VERY hesitant > > to place in such a crucial hub role in our LAN a box from a company who has > > just decided its system software is better manufactured by somebody else! > > Given DEC's past problems with system software, I see this as a hopeful sign. DEC's transgressions and omissions pale compared to SCO. Even idiocy like the dump vs super-user thing that recently re-surfaced. Things would be far worse in a multi-party system software environment where the customer service responsibility and the development responsibility are even further separated than present. Now, if DEC would just donate LAT and MIPS support to CSRG, I could punt on the whole mess and run 4.4 BSD (someday). 8-) 8-( -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
jallen@eeserv1.ic.sunysb.edu (Joseph Allen) (05/11/91)
In article <DV3B=4A@xds13.ferranti.com> peter@ficc.ferranti.com (peter da silva) writes: >In article <816@cadlab.sublink.ORG>, martelli@cadlab.sublink.ORG (Alex Martelli) writes: >> I hope this last rumor is wildly unfounded??? We're evaluating a centralized >> NFS server, and DS5500 was looking pretty good, but I would be VERY hesitant >> to place in such a crucial hub role in our LAN a box from a company who has >> just decided its system software is better manufactured by somebody else! >Given DEC's past problems with system software, I see this as a hopeful sign. >After all, you were already getting ready to buy a DEC product with a mostly >third-party O/S. Why not make it explicit? DEC is even reselling 386 PCs manufactured by Radio Shack (and that particular PC is the best computer I've ever seen Radio Shack make) -- /* jallen@ic.sunysb.edu */ /* Amazing */ /* Joe Allen 129.49.12.74 */ int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0) +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2 ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
mash@mips.com (John Mashey) (05/21/91)
In article <816@cadlab.sublink.ORG> martelli@cadlab.sublink.ORG (Alex Martelli) writes: > ... >:for OS software that has yet to be written, why did they need to pick two >:directions (times two hardware directions gives four?) instead of one? I >:may be missing something important, but this aspect of ACE sure looks like >:one of those "it's a dessert topping; it's a floor polish" skits. > >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. In the PC world: there are XT busses, AT busses, EISA busses, MCA busses. Much of this happened sort of by accident, and a lot of software knows too much about what's there, in gory detail. ACE assumes that ability to hit different price/performance areas, and to evolve, requires a sensible scheme for the inclusion of different busses, (or no bus at all), which after all, is done by most serious computer systems vendors. It is absolutely nuts to think that a bus in widespread use now [EISA, for example] is going to fulfill everybody's needs in 10 years. Hence, the ACE compatibility specifications are structured so that one can have a reasonable shrink-wrapped kernel that doesn't HAVE to know about the I/O bus choice, but still has enough info to be able to boot. This is a lot easier to do when starting from scratch with the experience of the last 10 years.... -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> 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
martelli@cadlab.sublink.ORG (Alex Martelli) (05/23/91)
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. You seem to be answering, and deeming 'nonsense', some different assertion, one which I did not make...: :In the PC world: there are XT busses, AT busses, EISA busses, MCA busses. :Much of this happened sort of by accident, and a lot of software knows too ^^^^^^^^^^ :much about what's there, in gory detail. ... :Hence, the ACE compatibility specifications are structured so that one can :have a reasonable shrink-wrapped kernel that doesn't HAVE ^^^^^^^^ :to know about the I/O bus choice, but still has enough info to 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. 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"). I should point out that this 'nonsense' is just personal opinion and interest - my employer is strictly a SW business anyway, so I guess it HAS no opinion on buses or anything as gross as that...:-) -- Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 53, Bologna, Italia Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; Fax: ++39 (51) 366964 (work only), Fidonet: 332/407.314 (home only).
mash@mips.com (John Mashey) (05/28/91)
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: <generic disclaimer, I speak for me only, etc> 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