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?"
There is clearly a lot of research going on, with results published, as in Raja's Optimal bandwidth utilization in wireless token ring networks released earlier this year. However, 1998 was the last big year for user's guides, which indicates that this technology has long since fallen from the mainstream and now survives only in academia.
About 5 years ago, I worked for a trucking company that was very heavily invested in token ring and would not consider switching to ethernet, no matter how compelling the argument was at that time. I can only imagine it's harder to justify staying on TR now, but it can't be cheap.
Its only advantage was that it could run at much higher utilization than ethernet without your network choking - we would see times where a ring would be running at 75% and that was no problem.
However, it was a real problem from a financial and operational standpoint. When we bought new PC's, we would rip out the ethernet cards and install Olicom TR cards we paid $180 each for - we got a good deal because we bought hundreds of them. Server-class cards were more - a lot more.
And we did get the 100Mb token ring switches, which was truly one of the more absurd things I have ever seen IT money spent on. I still don't have a clear idea how this was a good thing: you got a 100Mb token ring switch, which would create a ring on each port. Then you could plug exactly one device into each port, as long as it had a 100Mb token ring adapter. This was 5 years ago, and I remember that per port, it was price-competitive with Gig-E fiber.
Then there are the usual entertaining issues with drivers and growing the network. Need an extra PC at your desk? You can't just plug a hub in and go - you have to pull another cable from the wiring closet. You need certified drivers for your Windows cluster? How about a touch-screen network device for your truck terminals? A firewall? A NAS? No, you can't have any of those.
I know there are plenty of people who will swear by TR. You'll find the evolved version of this technology in FDDI rings - and it makes a lot of sense and works very well in that application. But as a LAN for your company, it sucks ass...technically, the concept is sound but nobody is developing it further and it takes a lot more specialized knowledge and maintenance overhead than ethernet. And every year that goes by makes it much more expensive to keep it than to switch to ethernet.
I turned down a job 3 years ago at a place that was still running TR - a mid-sized retail chain. They said they were starting to look in to ethernet, but were happy with their token rings. That was the deciding factor for me to keep looking...At this point, a company that isn't actively working to replace TR with something else has some serious management issues and I would wonder what else was lying inder the surface.
So if you can find a few cards and a MAU somewhere, experiment with it at home. But avoid it like the plague in a business setting. That's just my $.02 anyway.
I experienced P2P token ring back in college. Here's how it worked: a group of peers arranged in a circular manner would pass around a named pipe. Each peer would hit the pipe, a process known as token. After a while, the pipe would be cached, and a designated peer reloaded the pipe.
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.