Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site flairvax.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!wjh12!genrad!decvax!decwrl!flairvax!kissell
From: kissell@flairvax.UUCP (Kevin Kissell)
Newsgroups: net.lan
Subject: Re: Ethernet <=> Ethernet Link
Message-ID: <709@flairvax.UUCP>
Date: Sun, 5-Aug-84 16:04:25 EDT
Article-I.D.: flairvax.709
Posted: Sun Aug  5 16:04:25 1984
Date-Received: Wed, 8-Aug-84 00:22:16 EDT
References: <340@deepthot.UUCP>, <942@ulysses.UUCP>
Organization: Fairchild AI Lab, Palo Alto, CA
Lines: 25

With regard to distance limitations on Ethernet, they are defined
in order to provide guarantees of collision detection.  (There are
electrical considerations as well, but they are less restrictive.)
Violating distance spec will result in an increase in the probability 
of a collision going undetected, and thus of a damaged packet being
recieved.  So long as higher level protocols provide for error recovery,
a network can still run.  The increase in retransmissions is very small
so long as cable utilization remains relatively low.  Losing collision
detection *can* hurt you badly if you're using up 90%+ of your bandwidth.
Now, I'm not saying that the Ethernet distance specs should be treated
with the same disdain that many people show for the 50' RS-232 distance
restriction,  but I recall hearing about an experiment at ITT Belgium
where they ran some Ungermann-Bass gear down several miles of Ethernet
cable and still got what they considered to be very acceptable system
performance.  Of course, you break the rules at your own risk...

Kevin D. Kissell
Fairchild Research Center
Advanced Processor Development
uucp: {ihnp4 decvax}!decwrl!\
                             >flairvax!kissell
    {ucbvax sdcrdcf}!hplabs!/

"Any closing epigram, regardless of truth or wit, grows galling
 after a number of repetitions"