Path: utzoo!attcan!uunet!husc6!purdue!gatech!amdcad!rpw3
From: rpw3@amdcad.AMD.COM (Rob Warnock)
Newsgroups: comp.dcom.lans
Subject: Re: Can ethernet TCP/IP lock up?
Keywords: I don't know; someone says it can
Message-ID: <21674@amdcad.AMD.COM>
Date: 19 May 88 07:39:57 GMT
References: <299@fedeva.UUCP>
Reply-To: rpw3@amdcad.UUCP (Rob Warnock)
Organization: [Consultant] San Mateo, CA
Lines: 70

In article <299@fedeva.UUCP> wrd3156@fedeva.UUCP (Bill Daniels) writes:
+---------------
| Some folks in my organization have been led to believe that a "screaming" 
| modem/transceiver can lock up an ethernet by asserting carrier forever.
| Supposedly token stuff like GM/MAP does not permit this...
| What do you think?
+---------------

Any piece of hardware can fail. Your token-ring transmitters can go into
"screaming" mode, too. But well-designed hardware tries to avoid failing in
ways that will take down the whole net. In particular, Ethernet transceivers
(see the DEC/Intel/Xerox Ethernet spec) have what is called "jabber control"
to prevent exactly this kind of "screaming" (which is usually a controller
board fault, b.t.w., not the transceiver itself). The odds that a controller
will go beserk *AND* that the jabber control will have failed at the same time
are much less than either fault alone. And each fault is itself very rare.

Ethernet (*any* net!) usually suffers much more from: (1) badly planned cable
runs [such that the cable gets continual motion, for example]; (2) poor/broken
wires [due to #1, or just rough handling]; (3) badly trained installers;
(4) accidental damage by unrelated maintenance workers [as when changing a
fluorescent light]; (5) poor/broken software on the hosts [*sigh*]; (6) the
very robustness of upper-level protocols which hide problems from you. (All
of these also affect token systems.) Still, it's a *very* reliable technology.

As an aside, there seem to be a number of token advocates whose major style
of promoting token rings is to knock Ethernet, usually with some panic stories
about Ethernet "locking up" or "overloading". (From the tone of your question,
you have one or more of these in your organization.) Some of this comes from
not understanding Ethernet (which is a "controlled CSMA/CD" system, and does
not "collapse" like uncontrolled CSMA, or even uncontrolled CSMA/CD), while
some comes from politicking a vested interest.

While it is certainly possible to have a badly overloaded Ethernet (witness
some of the "broadcast storms" some diskless workstations can get into), it
is also just as possible to have a badly overloaded token net. *ANY* shared
resource will experience a sharp increase in delay as the average load exceeds
70-85%. (See any basic book on queueing theory.) There are good and bad points
about both Ethernet and token rings. (Just ask about recovering from a lost
token... Oops! There I go, doing what I was criticizing... ;-}  ;-}  )

Any technology needs to be analyzed for its suitablility before being used.
Token rings have a place in certain constrained process-control environments.
But note that even here you can't permit "general timesharing" on the same
net as your process-control, or you'll blow your real-time constraints.
Conversely, a dedicated Ethernet can be run as a "virtual token bus", and
meet essentially the same performance constraints. All such "guarantees",
however, assume there will be *NO* data errors, as these completely upset
the real-time constraints. (Hence my comment above about lost tokens.)

The major differences in performance between Ethernet and 10 Mbit/sec token
rings occur in the very-high-average-load regime, where you never want to
design a general-purpose net to run. At reasonable loads (under 70-85% or so),
the two technologies are practically identical. Also, token rings do better
at the higher data rates (above 50 Mbit/sec) or for geographically very large
nets (diameter >2500 meters), regimes where CSMA/CD doesn't work as well
(or at all!).

Anyway, Ethernet's there, it's (relatively) cheap (finally!), and everyone
from clone-makers to Big Blue supports it. Where it fits, it fits very well
indeed...


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun,attmail}!redwood!rpw3
ATTmail:  !rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403