home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / bit / listserv / biglan / 67 < prev    next >
Encoding:
Text File  |  1992-08-17  |  9.2 KB  |  193 lines

  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!SUVM.BITNET!BIG-REQ
  3. Message-ID: <BIG-LAN%92081808321671@SUVM.SYR.EDU>
  4. Newsgroups: bit.listserv.big-lan
  5. Approved: NETNEWS@AUVM.AMERICAN.EDU
  6. Date:         Tue, 18 Aug 1992 08:25:07 EDT
  7. Sender:       Campus-Size LAN Discussion Group <BIG-LAN@SUVM.BITNET>
  8. From:         BIG-REQ@SUVM.BITNET
  9. Subject:      BIG-LAN Digest, Volume 4, Number 54, Tuesday, August 18, 1992
  10. Lines: 181
  11.  
  12. BIG-LAN DIGEST           Tuesday, 18 August 1992       Volume 4 : Issue 54
  13.  
  14. Today's Topics:
  15.  
  16.                     Re: "evil" nature of hubs/hublets
  17.                            "two repeater rule"
  18.  
  19. Moderated by John Wobus, Syracuse University
  20.  
  21. Relevant addresses:
  22.                                   Internet                BITNET
  23. Submissions:              big-lan@suvm.acs.syr.edu     BIG-LAN@SUVM
  24. Subscriptions:    big-lan-request@suvm.acs.syr.edu     BIG-REQ@SUVM
  25. LISTSERV/Archives:       listserv@suvm.acs.syr.edu    LISTSERV@SUVM
  26. Moderator:                jmwobus@syr.edu              JMWOBUS@SYREDU
  27. Anonymous ftp archives:           syr.edu
  28.  
  29. Note: BIG-LAN is redistributed through many mailing lists at other sites
  30. run by other individuals.  If you subscribe(d) through such a
  31. "redistribution" list, you will need to remember its owner.
  32.  
  33. syr.edu also has a copy of the BIG-LAN "FAQ" memo (answers to frequently
  34. asked questions) under the path information/big-lan/big-lan.faq
  35.  
  36. ----------------------------------------------------------------------
  37.  
  38. Date:        Mon, 17 Aug 92 16:13:28 BST
  39. From:        Richard Letts <R.J.Letts@salford.ac.uk>
  40. Subject:     Re: "evil" nature of hubs/hublets
  41.  
  42. BIG-REQ%earn.SUVM@earn-relay.ac.uk writes....
  43. >
  44. > From: "John M. Wobus" <jmwobus@mailbox.syr.edu>
  45. > Subject:      Re: "evil" nature of hubs/hublets
  46. >
  47. > I mailed it out the first two times).  Here are the rules: there can be
  48. > no more than 4 repeaters and 3 coax segments between any two stations
  49. > on an Ethernet.  By "coax segment", I mean thickwire or thinwire.
  50. > The other segments can be fiber or twisted pair.
  51. >
  52. Nope, these aren't the rules:
  53.  -     You can have 3 data segments and 2 link segments between the
  54.     stations. (including the segments the stations are attached to)
  55.  -    Stations can only be connected to the 'data' segments
  56.  -    The segments can be of any type.
  57.  
  58. Richard
  59. - --
  60. Richard Letts            My opinions are my own, and do not necessarily
  61. Network Manager                 reflect those of my employer
  62. University of Salford               Email: R.J.Letts@salford.ac.uk
  63. United Kingdom                Phone : +44 61 745 5252
  64. United States of Europe
  65.  
  66. -------------------------------------------------------
  67.  
  68. Date: Mon, 17 Aug 92 12:29:13 -0400
  69. From: William H. Magill <magill@dccs.upenn.edu>
  70. Subject:      "two repeater rule"
  71.  
  72. > >    I suspect that the real problem is that you are violating the 2 repeater
  73. > >    rule. Both a "Hub" and a "hublet" are repeaters. Hence if you put
  74. > >    one "hublet" on a "hub" you are ok. but as soon as you put the second
  75. > >    "hublet" on you are probably in "theoretical violation" of the rule.
  76. > >
  77. > >I don't believe this is the case. ...
  78. >
  79. > I pulled the "I don't believe" out of context, but I want to make it
  80. > clear that adding a repeater may or may not extend you too far.  It
  81. > depends upon what's already in the network.  I made sure this was
  82. > documented in the latest BIG-LAN FAQ (though that part was cut off when
  83. > I mailed it out the first two times).  Here are the rules: there can be
  84. > no more than 4 repeaters and 3 coax segments between any two stations
  85. > on an Ethernet.  By "coax segment", I mean thickwire or thinwire.
  86. > The other segments can be fiber or twisted pair.
  87. >
  88. > The point is: add a hublet only if you aren't already 4 repeaters away
  89. > from some station on the ethernet.
  90. >
  91. The real issue in ANY CSMA/CD Carrier Sense, Multiple Access/Collision
  92. Detection - network ie. Ethernet IEEE 802.3 - is the ability for the two
  93. FURTHEST stations on a segment to "simultaneously" detect a collision,
  94. back-off and to retransmit. This dimension is measured in TIME, not feet.
  95. The FURTHEST separated stations are NOT necessarily the two stations which
  96. you are interested in. But they represent the LONGEST POSSIBLE path in TIME
  97. through that physical segment.
  98.  
  99. To quote from the spec: 4.1.22 Access Interference and Recovery
  100. "If multiple stations attempt to transmit at the same time, it is possible
  101. for them to interfere with each others transmissions, in spite of their
  102. attempts to avoid this by deferring. When transmissions from two stations
  103. overlap, the resulting contention is called a collision. A given station
  104. can experience a collision during the initial part of its transmission (the
  105. collision window) before its transmitted signal has had time to propagate
  106. to all stations on the CSMA/CD medium. Once the collision window has
  107. passed, a transmitting station is said to have acquired the medium;
  108. subsequent collisions are avoided since all other (properly functioning)
  109. stations can be assumed to have noticed the signal (by way of carrier
  110. sense) and to be deferring to it. The time to acquire the medium is thus
  111. based on the round-trip propagation of the physical layer whose elements
  112. include the PLS, PMA and physical medium."
  113.  
  114. PLS = Physical layer signaling
  115. PMA = Physical medium attachment
  116.  
  117. What all this is saying is that all of the "electrical characteristics of
  118. signal propagation" - voltage level, wave form shape, capacitance, etc. -
  119. control the whole ball game. This is why a "Fat Orange" Ethernet cable
  120. with a 90 degree kink in it becomes a major problem. Not because the braid
  121. and the conductor actually short out, but because the distortion effects
  122. the total signal propagation.
  123.  
  124. Because there is ONLY ONE way to determine the REAL characteristics of any
  125. given segment - and that is with expensive and extensive instrumentation
  126. (the minimum tool needed is a TDR) the original DIX crowd (Digital, Intel
  127. Xerox) formulated a series of "rules and budgets" that were "conservative"
  128. in their goal to achieve Interoperability. Consequently we find that a
  129. Segment can be so many meters in length if it is Fat Orange, or Thinwire,
  130. or Twisted Pair. Similarly, the individual components - taps, repeaters,
  131. connectors, etc were all given "budgets" based in feet to be subtracted
  132. from these maximums when designing a network.
  133.  
  134. The truth of the matter is that these numbers are "conservative" consistent
  135. with "sound installations." It is very true that in any given
  136. configuration, with any mix of hardware and at any given point in time, one
  137. can violate these "rules and budgets" with impunity. This becomes
  138. especially true with today's "faster" hardware. While the propagation delay
  139. of a "real" DEC DELNI might have been 10 feet back in 198? today, an
  140. equivalent 0>piece of equipment might be worth 2 feet. Similarly, any given
  141. vendor can give you very exact figures and rules for their own hardware in
  142. a homogeneous environment which far exceed the "Standard rules and
  143. budgets." But when asked to provide those same assurances in a mixed vendor
  144. environment, you will find that they will only "certify" the numbers
  145. mentioned in the standard.
  146.  
  147. You will also find that the physical topology of the network may NOT effect
  148. the logical use of the network. It is entirely reasonable that you might
  149. have a single segment with 3 distinct and essentially non-overlapping areas
  150. of logical interconnection - both ends and the middle. It is quite possible
  151. that these three groups might be able to conduct "reasonable" business on
  152. the same segment even though collectively they are violating the rules and
  153. impacting throughput.
  154.  
  155. As they say, your mileage may vary.
  156.  
  157. Some of the most evil things in this area are now surfacing in the 10BaseT
  158. world. Because the PC folks think that they invented radial wiring the are
  159. more than happy to ignore the experiences of Thinwire. The MOST EVIL thing
  160. which constantly occurs in a 10baseT wiring setup is "telephone-itis."
  161. It gets installed to look just like a telephone setup. But even
  162. "contemporary" telephone practice is ignored. (The Telephone world has
  163. discovered that Digital Switches are VERY unforgiving about wiring
  164. practices which worked for 50 years and more under POTS - plain old
  165. telephone service.) Since twisted pair "punches down" quite nicely on a
  166. "157 Block" in the wiring closet, they get used a lot. A 157 Block has a 25
  167. pair "amp" connector on the side making it very easy to "cross connect"
  168. two sets of things. The problem comes in that the 10BaseT spec only allows
  169. 1) a very short run 2) a limited number of splices and 3) very specific
  170. "twist" statements. So you find that two 157 blocks 4 feet apart, get
  171. interconnected by a "standard" 25 foot long Telco 25 pair cable.
  172. Not only do you suddenly have an extra 21 feet in your cable run, but you
  173. also have added 4 splices where they are not only unnecessary, but
  174. detrimental.
  175.  
  176. You wind up with:
  177. wallplate(cable)157block/J-connector/J-connector(cable)J-connector/J-connector/
  178. RJ45block/RJ45(cable)RJ45[hub].
  179.  
  180. Instead of:
  181. wallplate(cable)RJ45block/RJ45(cable)RJ45[hub].
  182.  
  183. William H. Magill                         Manager, PennNet Computing Services
  184. Data Communications and Computing Services (DCCS)  University of Pennsylvania
  185. Internet: magill@dccs.upenn.edu                   magill@eniac.seas.upenn.edu
  186.           magill@upenn.edu
  187.  
  188. -------------------------------------------------------
  189.  
  190.  
  191. End of BIG-LAN Digest
  192. *********************
  193.