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"