, X-NEWS: spcvxb alt.folklore.computers: 32845P Relay-Version: VMS News - V6.1B4+SPC1 6/9/92 VAX/VMS V5.5-2; site spcvxb.spc.eduX Path: spcvxb!rutgers!noao!arizona!arizona.edu!mvb.saic.com!unogate!news.service.uci.edu!Q  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"6 Message-ID: <1992Dec4.214516.27107@cis.ohio-state.edu>2 From: welch@sacral.cis.ohio-state.edu (Arun Welch) Date: 4 Dec 92 21:45:16 GMT 1 Sender: news@cis.ohio-state.edu (NETnews        )  Organization: OSU-LAIR	 Lines: 61   G OK, what follows is the text from the ethernet memo I talked about last D month. Of course, hindsight is 20/20, so it's wildly amusing in thisG day and age. I'm keeping the names of the various parties out of it. My H 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 B underline, I've used *'s instead to highlight. Note of caution: it *might* be a fake, I dunno.   J --------------------------------------------------------------------------  : 	I have read with dismay your presentation "Draft EthernetB Overview". As I am sure you are aware, technically or conceptuallyB 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 D credibility.  Quantitative statistical analysis would show that yourE proposed system would be a failure.  You have tried to adopt a scheme B inappropriate to the intended *engineering* application.  A randomC transmission scheme such as you propose,  along with the quasi-de-  F randomizing hardware you invoke to patch the obvious deficiency, wouldC place in fact an undo hardware, software, and scheduling problem on  the individual stations.  8 	You should seriously reconsider your basic premises and? formulate fully and logically *all* the parameters necessary to C evaluate the system. Your transmission medium or environment is not D quantum noise limited. Simple analysis shows that imposing a poissonE (i.e., random) statistics on message transmission drastically reduces > the available effective bandwidth.  Such a system is effectiveE (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* F system.  The fallacy in your conception is that the stations should beA transmitting randomly.  One possibility for a synchronized system D would be time division multiplexing.  You should seriously study howD the telephone companies handle this problem.  For example the A.T.T.C 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 C stations working at a 3Mbs rate. What is the nature of the station? B How many bits transmitted does an activity require and what is theF expected average rate that the 256 stations will be seeking use of theG bus in the contemplated application?  What is a tolerable dead time for D a given station to acquire a full set of data?  The worst case delayE for your 1 mile *loop* is ~2 usec.  What effect does this fave on far & stations getting locked out, etc. ...?  G -----------------------------------------------------------------------   D That's it. All spelling mistakes, except for the spelling of "undue" in the first para, are mine.     ...arun L ----------------------------------------------------------------------------
 Arun WelchC Lisp Systems Programmer, Lab for AI Research, Ohio State University  welch@cis.ohio-state.edu