🚀 go-pugleaf

In article <1992Dec18.031032.7378@netcom.com> nagle@netcom.com (John Nagle) 
writes:



>>	A few questions:

**questions deleted**

>>	- Given that Microsoft's NT supports multiprocessors (16 CPUs have
>>	  been demonstrated) and Compaq's position as a high-end vendor for
>>	  Microsoft-compatible iron, I'm suprised that Compaq is proposing an
>>	  I/O architecture that is single-CPU oriented.  Why?

**question deleted**

>>					   John Nagle

John,

  I'm not sure that I would agree that this Interconnect proposal from COMPAQ
is single-CPU oriented. Although I'm in no position to speak for them (or for
anybody but myself, for that matter) I would have to say that this was not my
impression of their posts and follow-up explanations.

>>>Warning: Liberal amounts of personal opinion to be found past this point<<<

  I happen to believe that modular I/O interconnects are a very good choice for
most of the market. In fact, I happen to believe that the day of the general
bussed interconnect that provides the system glue is past. If one considers the
rate of performance increase of memory devices and CPU designs I think that one
can understand that having these devices on the same bus with I/O devices is a
non-win. In fact, I personally believe that this was one of the driving points
behind the development of PCI as well (Intel needed to be able to bring out new
processors without forcing chip vendors to provide new glue logic for each CPU
bus change). Further, do you really want your CPU and Memory performance to be
bounded by this kind of bus? I much prefer a modular system design myself. I do
not think that having a SCSI controller or Token Ring interface or *put-your-
favorite-device-name-here* on the CPU to Memory interconnect is a good thing.
And I think that most of the PC manufacturers will decide the same thing fairly
soon (well, fairly soon may take a couple of years to catch on ;-)  so don't
hold my feet to the fire on timeframes).

  I also believe that the technology of Multi Media (a much over-used term) in
the sense of multi-person live video teleconferencing and such are more readily
served by a dedicated interconnect port with some reasonable guarantees of both
bandwidth and latency than by any shared resource scheme. Sure, today's version
of such performance is being done on such buses now. But, I think we can all
agree that the progress/quality of such applications is going to be compressed
into a much smaller timeframe soon. And for those of you who don't think that's
true I would remind you that it's not that many years ago that we were all
dreaming about the "3M" machine for the desktop.

		1 Million Instructions Per Second
		1 Megabyte Memory
		1 Megapixel Display

and look where the market is just 7 years later. And look how rapid a rise in
the progress curve we're currently undergoing. And some people said back then
that such a desktop machine was just a toy for the rich (didn't somebody say 
that about Television too?) that would never be high volume.

  Furthermore, I believe that such a point-to-point interconnect scales much
more readily than any shared wide bus implementation. Additionally, the signal
technology is much easier to handle at high frequencies in a point-to-point
implementation.

  One of the points that the COMPAQ proposal brought forward is that of support
for Live Insertion of option devices. I think that this is an important win in
market terms. It is FAR more difficult to support live insertion of an option 
to a shared bus interface (because of the impacts on the other options) than it
is in a point-to-point implementation. This is true for both the signalling and
the power considerations (arcing and voltage drops). Yet, for the "average PC
consumer" (and no, I wouldn't care to define that entity) I think that having
an option that they can plug into a running system and have it recognized and
auto-configured is a great benefit. I don't think most folks in this market are
thrilled by having to power off a machine, open it up, make their modifications
of adding a card, closing it back up and then trying to get it all up and going
again. I think this is a real win for configurability. Although, I would also
like to recommend some thought be given to Live Deassertion of options as well.
By this I don't mean Fault Tolerance. I'm talking about issueing a command to
quiesce the option module and then removing it. It will make for a much more
palatable system.


  Anyway, that's probably sufficient soapbox for a single post. As I said, the
above are simply my own personal viewpoints.

				Thanx,
				  AJ


      **********************************************************************
      * AJ Casamento			"The question is not whether or    *
      * Digital's TRI/ADD Program	 not the opinions are mine; but    *
      * 529 Bryant Ave. PAG-2		 rather, which of my personalities *
      * Palo Alto, CA 94301-1616	 do they belong to?"		   *
      * 415.617.3460							   *
      * ajc@pa.dec.com  						   *
      **********************************************************************