[comp.dcom.lans] HOW MANY REPEATERS ???

bobkil@ibmpcug.co.uk (Bob Kilgore) (01/30/91)

I have been reading the large number of messages that make
statements about HOW MANY REPEATERS CAN YOU HAVE in an Ethernet
(802.3) network.  Most comments seem to range around the picture
in chapter 8 of 802.3 or some vendors literature.

It seems to me the first question to ask is, what determines the
number of repeaters a network can have.  The second question is
WHY?  Anyone that is not on the 802 committee know?

Hint, it is obscure enough that you probably wont get the answer
from the 802.3 book, but I suggest you look in the supplement
with the full chapter 9.

802.3 is allegedly working on a document, that will not be part
of the standard, that will explain all the various topology
considerations as they understand them today.  This will also
contain the reason for limits and possibly the harm done if a
limit is exceeded. This sub-committee has been working for about
2 years.  You may want to let the 802 committee know that it is
important.

Post your answers and comments to the conf. so all can see the
importance of the topology information.  Are you watching Pat?

PS: One major problem the sub-committee has is the definition of a NETWORK.
-- 
Automatic Disclaimer:
The views expressed above are those of the author alone and may not
represent the views of the IBM PC User Group.
-- 

phil@dgbt.doc.ca (Phil Blanchfield DGBT/DIP) (02/07/91)

In article <1991Jan30.151500.23585@ibmpcug.co.uk> bobkil@ibmpcug.co.uk (Bob Kilgore) writes:
>
>I have been reading the large number of messages that make
>statements about HOW MANY REPEATERS CAN YOU HAVE in an Ethernet
>(802.3) network.  Most comments seem to range around the picture
>in chapter 8 of 802.3 or some vendors literature.
>
>It seems to me the first question to ask is, what determines the
>number of repeaters a network can have.  The second question is
>WHY?  Anyone that is not on the 802 committee know?

I am not on the 802 committee. Here is my answer to the above
question, please pick it to pieces.

The main reason for the maximum lengths of all cables (thick, thin
transceiver, UTP etc.) and maximum number of repeaters is timing.  Since
Ethernet is a baseband (single channel) network, only one station at a
time may transmit. However, since Ethernet is a multiple access network
(as opposed to a single access or token based network), two or more
stations may attempt to transmit at the same time. If this happens a
collision occurs. The transmitting station must listen for collisions
while it's transmitting, if a collision occurs during transmission that
station knows that its packet did not get through. If a station
completes the transmission of a packet and has not detected a collision
it may assume that the packet got through without collision.

Electrical signals take a finite amount of time to propagate from one
end of "a piece of wire" to the other. This propagation time is dependent
on the length of the wire and the conductive characteristics of the
wire. If a transmitting station, on one end of a wire, is to detect a
collision with another station, on the opposite end of the wire, during
transmission, it must transmit for at least as long as it takes for an
electrical signal to propagate from one end of the wire to the other
and back. The "and back" is important because there must be time for
the collision (another electrical signal) to propagate back to the
transmitting station. This end-to-end propagation time is called the
slot time or the minimum round trip delay, and is equal to 51.2 microseconds
for Ethernet. It is one of the key elements in the design of Ethernet
hardware.

Note that in the above paragraph "a piece of wire" in the context of
Ethernet means transceiver cables, transceivers, repeaters (single or
multi port) and any thick or thin Ethernet cable between the two
stations. All of these devices impose a delay in signal propagation.

The slot time and collision detection is the reason that Ethernet
has a minimum packet length of 72 bytes (46 data + framing). This
minimum packet size takes a greater amount of time to transmit than the
allotted slot time.

Calculation of minimum packet round trip delay:

Bit time = 100ns
Minimum Ethernet packet size = 72 bytes

(72 * 8 * 100 ns) = 57.6 microseconds 

The Ethernet cable length and maximum repeater restrictions insure that
the slot time is never violated. If the slot time on an Ethernet network
is violated by causing a large delay, the potential for disaster exists.
A transmitting station would incorrectly assume that its packet had reached
the destination without collision. It is difficult to predict all possible
problems that violating the Ethernet protocol in this fashion might cause.
In general a sharp rise in collisions would result, with the possibility
of a collision deadlock. It would be dependent on how greatly the actual
round trip delay exceeded the allotted slot time, the number of stations
and the average amount of traffic. Also, it would be nearly impossible
to regenerate the same set of conditions that would cause the trouble,
the events causing the trouble are asynchronous.

I have all too often seen people plug in an arbitrary chunk of cable and
if asked how long it is, reply, "Who cares, it works". They are headed for
disaster and disaster will strike whenever there are more users on their
Ethernet than ever before (Murphy's law of Ethernet).

Q. How come a Thicknet segment can be longer than a Thinnet segment?
A. Because the propagation speed of Thicknet is faster than Thinnet.

>Hint, it is obscure enough that you probably wont get the answer
>from the 802.3 book, but I suggest you look in the supplement
>with the full chapter 9.
>
>802.3 is allegedly working on a document, that will not be part
>of the standard, that will explain all the various topology
>considerations as they understand them today.  This will also
>contain the reason for limits and possibly the harm done if a
>limit is exceeded. This sub-committee has been working for about
>2 years.  You may want to let the 802 committee know that it is
>important.
>
>Post your answers and comments to the conf. so all can see the
>importance of the topology information.  Are you watching Pat?
>
>PS: One major problem the sub-committee has is the definition of a NETWORK.
>-- 
>Automatic Disclaimer:
>The views expressed above are those of the author alone and may not
>represent the views of the IBM PC User Group.
>-- 


-- 
Phil Blanchfield
The Communications Research Centre 3701 Carling Avenue, Ottawa Ontario CANADA
Internet: phil@dgbt.doc.ca	OR	phil@dgbt.crc.dnd.ca