Path: utzoo!news-server.csri.toronto.edu!rutgers!rochester!cornell!uw-beaver!mit-eddie!snorkelwacker.mit.edu!usc!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!uunet!pmafire!uudell!chinacat!cs.utexas.edu!ut-emx!!spurgeon
From: spurgeon@.uucp (Charles E. Spurgeon)
Newsgroups: comp.dcom.lans
Subject: Re: Ethernet performance degradation?
Keywords: PC, NFS, Novell, Netware, DOS
Message-ID: <45603@ut-emx.uucp>
Date: 14 Mar 91 19:30:05 GMT
References: <1991Mar7.220351.9761@uhura1.uucp> <1991Mar7.221028.9883@uhura1.uucp> <45323@ut-emx.uucp> <1991Mar11.133033.25283@jarvis.csri.toronto.edu>
Sender: news@ut-emx.uucp
Reply-To: spurgeon@atget.cc.utexas.edu.UUCP (Charles E. Spurgeon)
Distribution: usa
Organization: UTexas Computation Center, Austin, Texas
Lines: 80

In article <1991Mar11.133033.25283@jarvis.csri.toronto.edu> mart@csri.toronto.edu (Mart Molle) writes:
>spurgeon@atget.cc.utexas.edu (Charles Spurgeon) writes:
>
>>In article <1991Mar7.221028.9883@uhura1.uucp>, bryan@uhura1.uucp (Bryan
>>Curnutt) writes:
>>|>I've also heard (though I don't know how true it is) that Ethernet
>>|>network performance degrades drastically if too many nodes are added
>>|>to the network, and that the number of nodes to do this is relatively
>>|>small.  Is there any truth to this?
>
>value of the traffic generated by each station into an analytical model
>(e.g., Sohraby, et al., "Comments on `Throughput Analysis for Persistent
>CSMA Systems'", IEEE Trans. Comm., Feb. 1987) indicates that, depending
>on the packet size, adding too many hosts causes the percentage of dropped
>frames to skyrocket and the Ethernet utilization to plummet.  For 1024
>byte frames, the loss probability shoots up between 10 and 100 hosts,
>and the utilization drops off between 800 and 1200 hosts; for 64 byte
>frames the loss probability shoots up between 100 and 600 hosts and the
>utilization drops off between 100 and 500 hosts.

The Boggs, Mogul and Kent paper I cited in my reply to the original
post also contains some good advice for Ethernet implementation in
which they point out that you should not install long repeated
networks (use bridges or routers instead), and that you should try to
keep the number of hosts per cable segment down to a low roar.

Most campuses I'm aware of have used routers to limit the size of
Ethernet segments and to isolate themselves from the effects of
misconfigured hosts and high level protocols emitting lots of
broadcasts.  Chopping the Ethernets up into smaller chunks definitely
pays dividends in terms of reliability and manageability.

On the other hand, back in the old days before high performance
bridges and routers were readily available, large repeated networks
were built on campuses that got involved with networking early on.  At
Stanford there was a large 3 megabit experimental Ethernet that linked
a goodly number of hosts.  The main problem I recall with that system
was that every winter, when it rained in California, the old abandoned
cable plant that had been expropriated for this network would get
water in its conduits causing high levels of packet loss.  Once
things dried out, it tended to work fine. :-)

At the University of Texas, another major campus that used Ethernet
early on, the old campus network ran on a large fiber optic system
built using repeaters.  That too linked a good number of hosts and ran
for some time with lots of repeaters and long segments.

>3. Cite the experience of someone who has (apparently) actually tried 
>to run an Ethernet with that many hosts.  

Ok. I found an old copy of a paper written in 1986 at DEC in my piling
system, in which they monitor the operation of the Ethernet at their
Spit Brook Road, New Hampshire facility.  At the time this network
supported hundreds of nodes on segments linked to a backbone with
repeaters.  The backbone itself had a couple of LAN Bridges in it.
For the test they removed the LAN Bridges and ran the whole thing as
one big repeated system.

They were running 467 nodes, including 23 tips supporting 1,528
terminal lines.  The system was virtually all DECnet, SCA, and LAT
traffic and most of the packets were LAT packets and fairly small in
size.  This is pretty typical for a network back then - lots of
tip/terminal traffic.  During working hours their percentage of
utilization fluctuated between 15-22% with short spikes, sample period
was .5 seconds.  From the sounds of it, this network ran fine for
them.

I hasten to add that I wouldn't recommend that anyone set out to build
large repeated, or even bridged, networks.  With everything managed by
one group, running DECnet, and using multicasts like the network
described above, it obviously worked.  But anyone trying to manage a
heterogeneous network of that size, especially in a campus environment
where there is a lot of freedom and people tend to (mis)configure
hosts on their own, will find themselves dealing with a real
challenging job.

Dealing with the havoc that misconfigured or buggy hosts can cause on
a large repeated or bridged network can be pretty hair raising.
Routers, with their ability to block the propagation of broadcasts on
a network system, are known as "network firewalls" for good reason.