louie@cellar.bae.bellcore.com (Paul Louie) (11/03/90)
In the past few months, there were many auguments and counter auguments against and for using Token-Ring and Unshielded Twisted Pair (UTP) wires. The source of this debate I noticed range from systems integrators, LAN supervisors, and trade magazines. I like to know the experiences of the netters out there. This would resolve my curiosity and may help to steer away from a problem area. So what is it? Is the design of TRN not suitable to UTP or maybe that TRN has a very low tolerant and any bad connection or radiation can set it crazy. Thanks in advance for your comments, Paul
jbreeden@netcom.UUCP (John Breeden) (11/04/90)
In article <28522@bellcore.bellcore.com> louie@cellar.bae.bellcore.com (Paul Louie) writes: >In the past few months, there were many auguments and counter auguments >against and for using Token-Ring and Unshielded Twisted Pair (UTP) wires. >The source of this debate I noticed range from systems integrators, LAN >supervisors, and trade magazines. > >I like to know the experiences of the netters out there. This would >resolve my curiosity and may help to steer away from a problem area. >So what is it? Is the design of TRN not suitable to UTP or maybe that >TRN has a very low tolerant and any bad connection or radiation can >set it crazy. > True story: There's a mojor health insurance company in San Francisco that has two IBM 4/16 TR's running 3+ Open over TP (DIW). One of the rings runs near the windows facing San Francisco Bay. Every time a ship comes into port, the TR near the windows goes down due to ship's radar (it comes back up when the ship goes behind an island). Radar guns at trade shows can be fun too! (-: -- John Robert Breeden, netcom!jbreeden@apple.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden ------------------------------------------------------------------- "The nice thing about standards is that you have so many to choose from. If you don't like any of them, you just wait for next year's model."
henry@zoo.toronto.edu (Henry Spencer) (11/04/90)
In article <16135@netcom.UUCP> jbreeden@netcom.UUCP (John Breeden) writes: >... One of the rings runs near the >windows facing San Francisco Bay. Every time a ship comes into port, the TR >near the windows goes down due to ship's radar ... If you've ever wondered why thick Ethernet coax is such garden-hose stuff, it's precisely because it is designed to continue functioning even in the most frightful electromagnetic conditions. (Piddly little ships' radars are nothing, compared to a nearby broadcast transmitter at 10MHz -- the rumored worst-case design condition for thick Ethernet.) -- "I don't *want* to be normal!" | Henry Spencer at U of Toronto Zoology "Not to worry." | henry@zoo.toronto.edu utzoo!henry
bjm@f.gp.cs.cmu.edu (Bret Musser) (11/05/90)
Where I work (not CMU CS/RI), we run Novell, 3-Com 3+Share, OS/2 LAN Server and an IBM System/36 over the same UTP TRN (yes, simultanesouly) with very few problems. There are over 90 nodes on one ring -- we use repeaters to keep the signal strong and filters on each end node. The ring used to run over a distance covering 45+ stories, with no problems (we don't actively use that segment anymore). Our major problems come when a filter goes bad (usually someone moves their machine, pulling the wires, making a loose connection). This can create havoc because a loose connection will generate lots of noise onto the LAN. (The moral is to buy good quality filters -- and test each one before use.) We're pleased with the results so far (been in a few years), and we're adding a second UTP ring real soon now. BJM =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Bret J. Musser --- Carnegie-Mellon University --- bjm@f.gp.cs.cmu.edu "If you can count your money, you don't have a billion dollars." (J.P. Getty) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
cmilono@netcom.UUCP (Carlo Milono) (11/06/90)
The *real* problem with Token Ring is that there is only 802.5 and no true specifications on the 'nitty-gritty'. If you look at 'ethernet', you will find 802.3 - but, you will also see very explicit standards on it under the IEEE, i.e., 10BASE2, 10BASE5, 10BASET, etc. There are NO specifications for the transmission media for TR...in addition, the actual implementation is IMHO, antique. In an era where even my humble AM radio is fully solid-state, and my VCR is Digital, TR has mechanical relays (and depends on Analog Phase-Lock to remove jitter)...even the automotive industry is moving away from electro-mech relay technology. Go to a large TR installation and listen to the clatter...then find a 1950's Telephone Central Office and listen to the clatter...hmmm, is TR *really* '50's technology? -- +--------------------------------------------------------------------------+ | Carlo Milono | | Personal: netcom!cmilono@apple.com or apple!netcom!cmilono | |"Sometimes I think the surest sign that intelligent life exists elsewhere | | in the universe is that none of it has tried to contact us." B.Watterson | +--------------------------------------------------------------------------+
lstowell@pyrnova.pyramid.com (Lon Stowell) (11/06/90)
In article <28522@bellcore.bellcore.com> louie@cellar.bae.bellcore.com (Paul Louie) writes: >In the past few months, there were many auguments and counter auguments >against and for using Token-Ring and Unshielded Twisted Pair (UTP) wires. >The source of this debate I noticed range from systems integrators, LAN >supervisors, and trade magazines. > >I like to know the experiences of the netters out there. This would >resolve my curiosity and may help to steer away from a problem area. >So what is it? Is the design of TRN not suitable to UTP or maybe that >TRN has a very low tolerant and any bad connection or radiation can >set it crazy. It depends on whether you are running 4 or 16 Mbps Token Ring--and if 4, whether or not you intend to upgrade to 16. Token Ring runs quite nicely on UTP at 4 Mbit/sec. Since the FCC doesn't like radiation from the unshielded cable, a Media Access Filter is required (which may be imbedded in the T/R Adapter--a good choice..) to remove the higher harmonics of the Xmitted signal at each station's transmitter. This high-frequency roll-off, plus the lower transmission capability of UTP limits the physical span of T/R to ABOUT a third of that available with IBM Type 1 cabling. The problem is "jitter" with either implementation--UTP tends to hit the limit before Type 1... As long as you stay within the proper Lobe distance, keep the Main Ring Path within limits, UTP provides exactly the same error rate as Type 1. MOST installations have workstations well within UTP's range of the nearest MSAU.... You may combine Type 1 between MSAU's with UTP for Lobes for SOME increase in span in larger buildings compared to UTP (type 3) cable alone.... Several VAR's and aftermarket vendors push UTP well beyond IBM's cabling guidelines...as the IBM recommendations tend to be quite conservatively aimed at maximum reliability.... These aftermarket implementations seem to work quite well...symptoms of excessive length would be frequent Active Monitor changes and non-isolating error counts as jitter exceeds the ability of the stations to clock data reliably. 16 Mbit UTP is a different story. The IBM adapters APPEAR to work better than the T.I. based units (everyone but IBM...) although this is a hot area for manufacturer's and some fairly creative marketing claims from a few... There is nothing technically insoluble here, but tread carefully. If you have a ham radio background, look for Adapter cards with fully isolated ground and voltage planes for the Ring Interface circuitry with all signals buried between shielding layers. Look for good RF layout practices--even if at the expense of "pretty" component layout for ease of manufacturing. The TROLI modules from Pulse can help considerably, but poor RF layout can render even thes ineffective... Proteon has a unique solution for 16 UTP which (as I understand their implementation) re-clocks the ring data at each station. Although there are some possible losses in fault isolation, this re-clock approach has interesting possibilities for more reliable clocking--whatever the media....