X-NEWS: spcvxb alt.folklore.computers: 32845
Relay-Version: VMS News - V6.1B4+SPC1 6/9/92 VAX/VMS V5.5-2; site spcvxb.spc.edu
Path: spcvxb!rutgers!noao!arizona!arizona.edu!mvb.saic.com!unogate!news.service.uci.edu!
 usc!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!sacral.cis.ohio-state.edu!welch
Newsgroups: alt.folklore.computers
Subject: Comments on "Draft Ethernet Overview"
Message-ID: <1992Dec4.214516.27107@cis.ohio-state.edu>
From: welch@sacral.cis.ohio-state.edu (Arun Welch)
Date: 4 Dec 92 21:45:16 GMT
Sender: news@cis.ohio-state.edu (NETnews        )
Organization: OSU-LAIR
Lines: 61

OK, what follows is the text from the ethernet memo I talked about last
month. Of course, hindsight is 20/20, so it's wildly amusing in this
day and age. I'm keeping the names of the various parties out of it. My
copy is yellowed with age, and I have no idea how many copiers it's been
through. The original date on it is March 1974. Since I can't
underline, I've used *'s instead to highlight. Note of caution: it
*might* be a fake, I dunno.

--------------------------------------------------------------------------

	I have read with dismay your presentation "Draft Ethernet
Overview". As I am sure you are aware, technically or conceptually
there is nothing new in your proposal.  Perhaps appropriately, you
have chosen a coined jargon utilizing discredited scientific
conceptual expression in which to frame your ideas.  I find your
analysis of the proposed interconnection lacking in technical
credibility.  Quantitative statistical analysis would show that your
proposed system would be a failure.  You have tried to adopt a scheme
inappropriate to the intended *engineering* application.  A random
transmission scheme such as you propose,  along with the quasi-de- 
randomizing hardware you invoke to patch the obvious deficiency, would
place in fact an undo hardware, software, and scheduling problem on
the individual stations.

	You should seriously reconsider your basic premises and
formulate fully and logically *all* the parameters necessary to
evaluate the system. Your transmission medium or environment is not
quantum noise limited. Simple analysis shows that imposing a poisson
(i.e., random) statistics on message transmission drastically reduces
the available effective bandwidth.  Such a system is effective
(reasonable) only in the limit of negligible average bit transmission
rates.  In fact you will want to maintain as high an effective
transimission rate as possible.  This requires a *synchronized*
system.  The fallacy in your conception is that the stations should be
transmitting randomly.  One possibility for a synchronized system
would be time division multiplexing.  You should seriously study how
the telephone companies handle this problem.  For example the A.T.T.
Long Lines T2 buried microwave link multiplexes close to 10^7-6 KHz
channels.

	Most importantly, you should fully define your *engineering*
application before proceeding further.  You specify an undefined
message packet length, a 1 mile or 1 mile diameter loop and 256
stations working at a 3Mbs rate. What is the nature of the station?
How many bits transmitted does an activity require and what is the
expected average rate that the 256 stations will be seeking use of the
bus in the contemplated application?  What is a tolerable dead time for
a given station to acquire a full set of data?  The worst case delay
for your 1 mile *loop* is ~2 usec.  What effect does this fave on far
stations getting locked out, etc. ...?

-----------------------------------------------------------------------

That's it. All spelling mistakes, except for the spelling of "undue"
in the first para, are mine. 

...arun
----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
welch@cis.ohio-state.edu