Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!freedom!cornutt
From: cornutt@freedom.msfc.nasa.gov (David Cornutt)
Newsgroups: comp.dcom.lans
Subject: Re: Ethernet collisions
Message-ID: <1990Dec14.191255.20529@freedom.msfc.nasa.gov>
Date: 14 Dec 90 19:12:55 GMT
References: <467@pirates.UUCP> <2184@cybaswan.UUCP> <1990Dec11.174941.12301@zoo.toronto.edu>
Organization: MSFC
Lines: 37

The percent utilization of the channel capacity of an Ethernet (or any
CSMA-type network) depends not so much on the total volume of traffic as
on the number of nodes that have traffic ready to transmit simultaneously. 
As Henry Spencer noted in a previous article, an Ethernet with only one
node transmitting can get pretty close to 100% utilization.  (Such
situations do occur; we have an application here where there may be about
70 nodes on a net, but only one or two nodes generating the lion's share of
the traffic.)  The limiting factor is the probability of getting a
collision, which is roughly proportional to the number of nodes that are
generating large amounts of traffic.  There is a derivation in the
Tannenbaum book (*Computer Networks*, second edition, Prentice Hall, 1988)
which can be expanded to show the expected utilization for n number of
nodes transmitting (or attempting to) simultaneously.  The theoretical
worst case occurs about n = 100, where the channel utilization is down to
about 37%.  (I have seen values close to this in a campus network that I
once worked on.)  In practice, an Ethernet starts to break down at this
point as controllers begin giving up due to exceeding their max retry
settings.

There are ways to make CSMA networks get better utilization under these
conditions by introducing a random go/no-go decision into retransmissions. 
A node attempts to retransmit picks a random number such that it has an x%
chance of attempting the retansmit; if the random draw loses, the node does
not attempt retransmission but backs off again.  The lower x gets, the
better the overall channel utilization gets.  The tradeoff is that the
average latency for individual packets becomes very long as x increases,
which is why you don't see many commercial implementations of this scheme. 

Of course, none of the above figures take into account the overhead
introduced by upper layer protocols.


-- 
David Cornutt, New Technology Inc., Huntsville, AL  (205) 461-6457
(cornutt@freedom.msfc.nasa.gov; some insane route applies)
"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."