home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / bit / listserv / biglan / 68 < prev    next >
Encoding:
Text File  |  1992-08-21  |  10.0 KB  |  232 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%92082109044929@SUVM.SYR.EDU>
  4. Newsgroups: bit.listserv.big-lan
  5. Approved: NETNEWS@AUVM.AMERICAN.EDU
  6. Date:         Fri, 21 Aug 1992 08:53:30 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 55, Friday, August 21, 1992
  10. Lines: 220
  11.  
  12. BIG-LAN DIGEST            Friday, 21 August 1992       Volume 4 : Issue 55
  13.  
  14. Today's Topics:
  15.  
  16.                                 Crosstalk
  17.                        More on Repeater Count Rules
  18.                          Daisy Chaining 10BT hubs
  19.                      Ethernet card to IBM RISC-6000?
  20.                          Those pesky "hub" rules
  21.  
  22. Moderated by John Wobus, Syracuse University
  23.  
  24. Relevant addresses:
  25.                                   Internet                BITNET
  26. Submissions:              big-lan@suvm.acs.syr.edu     BIG-LAN@SUVM
  27. Subscriptions:    big-lan-request@suvm.acs.syr.edu     BIG-REQ@SUVM
  28. LISTSERV/Archives:       listserv@suvm.acs.syr.edu    LISTSERV@SUVM
  29. Moderator:                jmwobus@syr.edu              JMWOBUS@SYREDU
  30. Anonymous ftp archives:           syr.edu
  31.  
  32. Note: BIG-LAN is redistributed through many mailing lists at other sites
  33. run by other individuals.  If you subscribe(d) through such a
  34. "redistribution" list, you will need to remember its owner.
  35.  
  36. syr.edu also has a copy of the BIG-LAN "FAQ" memo (answers to frequently
  37. asked questions) under the path information/big-lan/big-lan.faq
  38.  
  39. ----------------------------------------------------------------------
  40.  
  41. Date:         Tue, 18 Aug 92 10:28:48 EST
  42. From:         Jack Lubowsky <LUBOWSKY@SNYBKSAC>
  43. Subject:      Crosstalk
  44.  
  45. A contractor has just wired our building with 10Base-T to the floors
  46. from fiber risers. The 10Base-T cable (4 pair of #24) has been wired
  47. through carrels in the labs alongside unshielded ac power cables. The
  48. power cables are typical lab use lines (ie: not running heavy machinery)
  49. and the runs can be as long as 20 feet.
  50.  
  51. Does anyone know whether there will be crosstalk problems sufficient to
  52. reduce performance. The decision is, do we...
  53.       1: leave things alone, it will probably be ok,
  54.       2: move the twisted pair cable and power cable apart and secure
  55.              with wire ties anywhere we can, (Could be labor intensive)
  56.       3: require the contractor to pull back the twisted pair and rerun
  57.              to minimize proximity to power cable?
  58.  
  59. Any experiences or advice would be apreciated....Thanks
  60.  
  61. -------------------------------------------------------
  62.  
  63. Date: Tue, 18 Aug 92 16:03:34 CST
  64. From: Andrew Birner <birnera@Janus-ccm.zenithe.com>
  65. Subject:      More on Repeater Count Rules
  66.  
  67. In BIG-LAN 4.54, William Magill <magill@dccs.upenn.edu> writes:
  68.  
  69. >The real issue in ANY CSMA/CD Carrier Sense, Multiple Access/Collision
  70. >Detection - network ie. Ethernet IEEE 802.3 - is the ability for the two
  71. >FURTHEST stations on a segment to "simultaneously" detect a collision,
  72. >back-off and to retransmit. This dimension is measured in TIME, not feet.
  73. >The FURTHEST separated stations are NOT necessarily the two stations which
  74. >you are interested in. But they represent the LONGEST POSSIBLE path in TIME
  75. >through that physical segment.
  76.  
  77. While this is true, it is only half the story of the the repeater rule.  The
  78. other half has to do with inter-frame gap shrinkage:  Repeaters make frames
  79. longer, so if you have too many repeaters, they use up all the space between
  80. the frames.  Seriously.
  81.  
  82. A repeater doesn't start repeating until it knows it has something to repeat.
  83. Since frames are generated asynchronously, the repeater has to see some
  84. number of bits before it can sync up to the signal and determine that a frame
  85. is coming in; this is the function of the frame preamble--to give the
  86. receiver (in this case a repeater) something to synchronize to.  Detecting
  87. and synchronizing to the signal consumes some number of preamble bits,
  88. however; the exact number consumed for any given frame is indeterminate, but
  89. must be less than some number (12, I think).  So, receiving the frame
  90. essentially makes it "shorter", since preamble bits are included in the frame
  91. size.
  92.  
  93. However, the specs require a minimum preamble length.  So, the repeater needs
  94. to regenerate any preamble bits it consumed, on the assumption that the
  95. transmitter generated the minimum allowed; but, the receiver doesn't know how
  96. many it consumed!  The repeater does, however, have an upper bound (namely,
  97. the maximum permitted by the standard) on the number of bits it consumed; so,
  98. it adds that number of bits to the preamble of the outgoing frame.
  99.  
  100. If, as is usually the case, the repeater actually consumes less than the
  101. maximum number of preamble bits, the outgoing frame will be longer than the
  102. incoming frame.  Thus, the end of the frame will be displaced backwards in
  103. time, relative to the front of the frame; this brings it closer to the front
  104. of any following frame on the wire!  If two successive frames start out
  105. spaced at the minimum time/distance, they may be indistinguishable to a
  106. receiver after some number of repeaters!
  107.  
  108. Note that this preamble restriction is a function of the broadcast nature of
  109. "coax" segments.  Inter-Repeater Link (IRL) segments are full-duplex, point-
  110. to-point links; they are implemented such that the receiver does not need to
  111. consume preamble bits to detect the start of a frame.  (In some synchronous
  112. implementations, code violations are used, as I recall).  Thus the different
  113. rules for coax versus IRL segments in the repeater-count rules.
  114.  
  115. Andrew Birner
  116. Zenith Electronics Corporation
  117.  
  118. -------------------------------------------------------
  119.  
  120. Date:        Wed, 19 Aug 92 09:13:00 EDT
  121. From:        NCUT000 <NCUT@SLUMUS>
  122. Subject:      Daisy Chaining 10BT hubs
  123.  
  124. While it's true that "Daisy Chaining" counts as a repeater hop when you
  125. connect from the up/down ports that is NOT the only answer to the
  126. question - 3Com makes a 12 port hub that can be interconnected to
  127. another of the same type via a backplane scsi 2 connector.  Using this
  128. backplane connector you can stack 4 hubs on "top" of each other and the
  129. entire stack still only counts as one repeater hop.  We have just
  130. received a few of these to put into our labs.  Having not actually
  131. installed them yet I can't comment on my satisfaction or
  132. dis-satisfaction, but I suspect they will work just fine.  We decided
  133. to try these for this feature and a number of other quite well thought
  134. out features that 3Com has built in.   These are the 10BT series
  135. concentrator.
  136.  
  137. - - Sorry if that sounded like a sales pitch.  'Just thought you should
  138. know.
  139.  
  140. Nick Cutry                         voice: (315)379-5971
  141. Network Manager                    Bitnet: NCUT@SLUMUS or CUTRY@STLAWU
  142. Computer Services                  Compu$erve: 76424,144 or 73257,2537
  143. St. Lawrence University
  144.  
  145. "...so they are protecting all of us PC users from having our computers
  146. made obsolete."
  147.               - Peter Norton on IBM's intro. of the PC/XT (march '83)
  148.  
  149. -------------------------------------------------------
  150.  
  151. Date: Thu, 20 Aug 1992 16:48 -0300
  152. From: Marcelo Spohn <SPOHN@VORTEX.UFRGS.BR>
  153. Subject:      Ethernet card to IBM RISC-6000?
  154.  
  155.         Please,
  156.  
  157.         Anyone can tell me if there is other supplier than IBM
  158. of Ethernet cards for IBM RISC-6000 workstations?
  159.  
  160.         Thanks in advance!
  161.  
  162. MARCELO SPOHN
  163. Federal University of Rio Grande do Sul - UFRGS
  164. Institut of Informatic
  165. Data Communication Group
  166. Porto Alegre - RS - BRAZIL
  167.  
  168. -------------------------------------------------------
  169.  
  170. Date: Fri, 21 Aug 92 08:47:28 -0400
  171. From: "John M. Wobus" <jmwobus@mailbox.syr.edu>
  172. Subject:      Those pesky "hub" rules
  173.  
  174. Richard Letts writes:
  175. >> From: "John M. Wobus" <jmwobus@mailbox.syr.edu>
  176. >>
  177. >>                                        Here are the rules: there can be
  178. >> no more than 4 repeaters and 3 coax segments between any two stations
  179. >> on an Ethernet.  By "coax segment", I mean thickwire or thinwire.
  180. >> The other segments can be fiber or twisted pair.
  181. >>
  182. >Nope, these aren't the rules:
  183. > -     You can have 3 data segments and 2 link segments between the
  184. >    stations. (including the segments the stations are attached to)
  185. > -    Stations can only be connected to the 'data' segments
  186. > -    The segments can be of any type.
  187.  
  188. Actually, what Richard Letts said and what I said are very close: 4
  189. repeaters is enough to connect 5 segments, i.e., 3+2.  The kinds
  190. of segments defined by the standards include two that are point to
  191. point (10BASE-T and FOIRL) and two that can have lots of stations
  192. connected to them (10BASE-5/thickwire and 10BASE-2/thinwire).  So the
  193. only differences are the choice of terminology, the fact that my
  194. statement of the rules allowed more link segments as long as the
  195. total is not more than 5 and that Richard's definition of data segments
  196. was that there are stations on them rather than that they are coax.
  197.  
  198. The relevant chapter of the standard (Section 13, System Considerations
  199. for Multisegment 10 Mb/s Baseband Networks) has been rewritten more
  200. than once to "clarify" it.  The latest standardized version is in IEEE
  201. Std 802.3i-1990, the 802.3 supplement that includes 10BASE-T.  The
  202. relevant sentence is item (4) on page 16:
  203.  
  204.    (4) When a network path consists of four repeater sets and five
  205.        segments, up to three of the segments may be coax and the
  206.        remainder must be link segments.
  207.  
  208. William H. Magill writes:
  209. >> From: "John M. Wobus" <jmwobus@mailbox.syr.edu>
  210. >>
  211. >> The point is: add a hublet only if you aren't already 4 repeaters away
  212. >> from some station on the ethernet.
  213. >>
  214. >The real issue in ANY CSMA/CD Carrier Sense, Multiple Access/Collision
  215. >Detection - network ie. Ethernet IEEE 802.3 - is the ability for the two
  216. >FURTHEST stations on a segment to "simultaneously" detect a collision,
  217. >back-off and to retransmit. This dimension is measured in TIME, not feet.
  218.  
  219. William Magill is right.  I was quoting the standard which actually
  220. promotes an "easy way" of maintaining the necessary time constraints:
  221. by counting lengths and repeaters rather than caclulating a time
  222. budget.
  223.  
  224. John Wobus
  225. Syracuse University
  226.  
  227. -------------------------------------------------------
  228.  
  229.  
  230. End of BIG-LAN Digest
  231. *********************
  232.