🚀 go-pugleaf

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