Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site cornell.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxb!mhuxn!mhuxm!mhuxj!houxm!vax135!cornell!jqj From: jqj@cornell.UUCP (J Q Johnson) Newsgroups: net.lan Subject: Re: Stretching the Ethernet specs Message-ID: <1854@cornell.UUCP> Date: Fri, 1-Feb-85 13:27:24 EST Article-I.D.: cornell.1854 Posted: Fri Feb 1 13:27:24 1985 Date-Received: Sun, 3-Feb-85 09:00:07 EST References: <425@mcvax.UUCP> <771@rocksvax.UUCP> Reply-To: jqj@gvax.UUCP (J Q Johnson) Organization: Cornell Univ. CS Dept. Lines: 29 Summary: I don't have any information on other repeater vendors, but I gather that the DEC Ethernet repeater is advertised NOT to eat any preamble bits. It does, of course, contribute to the propagation delay budget as the Ethernet spec. allows. This would seem to imply that an Ethernet using only DEC repeaters could comfortably have more than 2 repeaters between a pair of nodes if the maximum cable distance between nodes was suitably reduced. For example, consider the following topology which violates the spec in various ways: ( 500m Ethernet backbone) ---------------------------------------------------------------- R R R |(500m seg) |building 2 (500m seg)| building 1 | building 3 (500m seg)| building 4 ________/R--------------------- The fact that the repeater for building 2 is in the middle of the backbone Ethernet would seem to imply that the delay budget for the repeater connecting to building 4 can be safely ignored. Of course, in practice you would have to figure the delay budget carefully to make sure everything worked. The advantage of the Ethernet spec as written is partially that it is fairly simple -- you don't have to calculate delay budgets between every possible pair of nodes. Since configuring an Ethernet is already a complex undertaking, making it still more complex by permitting some but not all configurations of multiple repeaters seems like a dangerous idea.