Slashdot Mirror


Does Anyone Still Use Token Ring?

blanchae asks: "Does anyone still use Token Ring, or is it dead? I remember hearing about 100 mbps TR a few years ago but nothing since. I remember that the strong point of TR over Ethernet was the QOS and the consistent response time. Does the banking community still use TR?"

5 of 185 comments (clear)

  1. token ring usage by Anonymous Coward · · Score: 3, Interesting

    This is the first time I see slashdot post with 0 comments; I guess it means something for tokenring's popularity :-).

    100mbps version existed, but AFAIK tokenring is now extinct. Everyone is moving to wifi, anyway.

    1. Re:token ring usage by Bush+Pig · · Score: 3, Interesting

      I was working at Mitsubishi Australia a couple of years ago, and they still had some token ring. It was quite weird to see half the office unable to work and the other half saying, "What's your problem?" when either the token ring or the ethernet failed for some reason.

      It's redundancy, of a kind ...

      --
      What a long, strange trip it's been.
  2. Some still exists by anticypher · · Score: 4, Interesting

    I see token ring still in use in bank branches, main bank data processing centres, and some insurance companies. NATO is rumoured to have a bunch of legacy systems on TR. On the PC side, its mostly old ISA cards, and the 486-PII era machines which still have some crappy 32x0 emulator running in fullscreen mode on OS/2. On the the mainframe side, there are still old IBM 3080s+3090s, system 36/37/38s and many C390s around. Be afraid, be very afraid.

    One of the side effects of some companies locked into dino^H^H^H^Hlegac^H^H^H^Htime tested solutions, is that they have to pay whatever it takes for dino^H^H^H^Hexperienced old-fa^H^Htimers to come in and fix the fsckups caused by young ignoramuses not having any knowledge of TR. My going rate right now is EUR400/hour, with a minimum of an 8 hour payment up front before I even set foot on the premises, and I still get called out about 3 times per year. get off my lawn...

    Cisco must still have TR, I met a dejected CCIE candidate who told me he paid many thousands of euros for a one week CCIE-mill course, which took him from windoze point and click to supposedly a CCIE, only to have half his stack be wired with TR which the fly-by-night company had never heard of. Clearly the CCIE proctors have some tricks up their sleeves when they detect a candidate who has all the answers but none of the experience.

    the AC
    As well, my cisco study kit still has some 2513s and AGS+s and a box of TR cables (hermaphrodite and RJ45), ISA cards, and some 8228s. I haven't touched any of it in at least 5 years

    --
    Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
  3. Not even at IBM... by sirwired · · Score: 4, Interesting

    Myself and my wife work for IBM. One of my wife's first jobs at IBM was writing Token Ring drivers for early iterations of the NDIS interface. She had to write all the code on a 3270 terminal connected to a mainframe and cross-compile to the PC because the PC's couldn't handle the code. I joined the company two months before the Networking Hardware Division (which made Token Ring cards, ATM switches, Ethernet switches, mainframe communication devices, and Multiprotocol Routers) was paid $2B by Cisco to go out of business.

    The Token Ring products were withdrawn from marketing a couple of years ago, so no more MAU's and Concentrators or NICs can be purchased, at least not from IBM. However, the products are still supported, and not uncommon in mainframe installations.

    At IBM we finished the Ethernet migration a couple of years ago. The thing that struck me the most about the migration was how converting from 14Mbps TR cable to 100Mbps Ethernet cable involved nothing more than inserting an adapter cube into the connector on each end of the building cabling. One of the primary features of the "IBM Cabling System" was that it could be adapted to many different cable types by just using adapters; coax, twinax, UTP, etc. To accomplish this feat, it was actually shielded, as opposed to unshielded CAT3/5, etc. This made it hideously over-specc'd for the original common use of TR. The cabling was designed so you could run it past just about anything and not have to worry about interference, cross-talk, etc. You could even get cable that had some UTP pairs stuffed between the shielding and the sheath so you could run your phone and data cabling using the same cable run.

    The drawback was that the cabling was bulky, expensive, and difficult to work with.

    Making cable that will actually work at over six times it's origninal intended speed while being more than a bit difficult to work with is an interesting example of Enterprise-quality engineering philosophy at IBM from the '80s.

    SirWired

  4. Why Ethernet didn't work, the real story by Animats · · Score: 5, Interesting
    The big deal with token ring was that the network would remain stable under 100% load. Classic 10mbps ethernet with hubs would start experiencing trouble around 60% load and collapse by the time load reached 90%. If you had a big, flat network it just plain wouldn't work.

    In theory, Ethernet on coax should be stable under heavy load. But in the late 1980s and early 1990s, it wasn't, due to defective design of some widely used interface chips. Here's the actual story. See this note by Wes Irish at Xerox PARC

    The worst device was the SEEQ 8003 chip, found in some Cisco and SGI devices. Due to an error in the design of its hardware state machine, it would turn on its transmitter for a few nanoseconds in the middle of an interframe gap. This noise caused other machines on the LAN to restart their interframe gap timers and ignore the next packet, if it followed closely enough. This happened even if the SEEQ chip was neither the sender or the receiver of the packets involved. So as soon as you plugged one of these things into a LAN, throughput went down, even if it wasn't doing anything. A network analyzer wouldn't even see the false collision; this was at too low a level.

    This was tough to find. Wes Irish worked on the problem by arranging for both ends of Xerox PARC's main coax LAN to terminate in one office. Then he hooked up a LeCroy digital oscilloscope to both ends. Then he tapped into a machine with an Ethernet controller to bring out a signal when the problem was detected and trigger the oscilloscope. Then, when the problem occured, he had a copy of the entire packet as an analog waveform stored in the scope. This could then be printed with a thermal printer and gone over by hand.

    Because he had the same signal from both ends of the wire, the wierd SEEQ interference mentioned above appeared time-shifted due to speed of light lag, making it clear that the interference was from a different node than the one that was supposed to be sending. You could measure the time shift and figure out from where on the cable the noise was being inserted. Which he did.

    It took some convincing to get manufacturers to admit there was a problem. It helped that Wes was at Xerox PARC, where Ethernet was born. I went up there to see his work, and once I saw the waveforms, I was convinced. There was much faxing of waveform printouts for a few months, and some vendors were rather unhappy, but the problem got fixed.

    So that's why.