Slashdot Mirror
Linux Token Ring Support Bringing Down Corporate Nets?
"My company runs Token Ring at the office (puke!) I got drivers from the card manufacturer (Madge), and I'd been happily churning along. Then last week, we started seeing a bunch of errors on the network. These errors would bring everyone on the ring down. After a week of this kinda stuff, they eventually isolated it to me.
Reboot the laptop into Windows and the network card works just fine and they don't see any ring errors. Reboot into linux, and suddenly they start seeing ring errors. I don't really grok token ring, so I'm not entirely certain that I know exactly what the problem is. But, whenever I brought the token ring on line under linux, they saw ring errors, which eventually (as I understand it) would bring down the entire ring. Switch cards (same model) and it continues to happen. It looked to me (and the network analysts) that the Linux driver was causing the problem.
I tried switching to an IBM token ring card, but there's a bug and I hadn't patched for this. The people with the fluke would not wait around while I tried to figure this out. I didn't have any other token ring cards that I could try.
In the end, I agreed not to boot into Linux unless I went into the conference room (which is one of the only rooms in the building with ethernet ports). How should I have done this differently so that using Linux would have been a more positive experience for my company?"
No excuse. If you say you support something and that support is stable... it should be so.
Fix it... don't say its not worth having anyway. Or if its not worth having strip token ring support out and save a few kB.
I have a Linux box that's been on my company's token ring for nearly three years (I work for IBM), using an Olicom card. Not only do the sysadmins not bug me about it, they use it on a regular basis. It's my team's development server, but the network admins come to me quite frequently with some little thing they'd like to try or some temporary service they need to provide and they find that my box is the simplest and most reliable place to do those things (the other local servers are NT and OS/2; there are plenty of AIX boxes around, but they're not at my location and the local sysadmins don't really have access to them).
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
The token is falling out, and getting caught in the ether net? You'd better go looking for it on the floor around you... :)
I had the same thing with a Microsot implementation of DHCP taking down My SCO server. I found a patch on SCO's website, which completely resolved this issue.
Perhaps the biggest problem in the computing industry in general, and in mixed os environments in general, is the fact that standards are often never actually standards. Even without casting blame on any of the products in question, standards are often not as defined as they should be, and any liberties or assumptions made by programmers, usually ends up in catastrophic incompatibilities. Regardless of where the blame lies (MS, BSD or Linux not following standards), the solution is to viehemently define standards so that there is no question about their implementation.
If you already have ethernet in a conference room it might not be too hard to just have the port you use added to whatever hub they use for the conference room.
It seems that you are running on a laptop since you can move you computer to the conference room. Another option is to insist that they put up an 802.11b network. You could then wander freely and have wireless ethernet. Even better!
Lasers Controlled Games!
Well, first, debug the whole thing beforehand. By then, you'll find out about it and will be able to accomidate.
Now, I'm unsure on Token Ring. I'm taking that it runs on coax cabling and you have to be in a loop for every computer to work. UGH! I'm unsure of the protocalls used with it, but if it can run TCP/IP on it, you may be able to get away with a gateway computer (which does TokenRing <==> Ethernet.)
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
Not true. There's gigabit TokenRing just like there's gigabit Ethernet. What's more, TR has collision avoidance built into the protocol, where Ethernet networks have to be architected in star topologies to avoid collision, because Ethernet responds horribly.
Of course, Ethernet costs so little that you can build an Ethernet in a star topology for less than a TokenRing in a ring topology. "Good enough" wins again.
If you have a reproducable problem that causes the entire network to fall over, the only thing you can do is pull the machine. On the other hand, you should really get in touch with the developer of the driver you were using. It's possible that this bug is known and a fixed version of the driver exists, or it's possible that nobody's ever seen it before. Either way, doing what you can to help the developer get this fixed will help prevent other people from having the same problems in the future. You should be able to find out who's responsible for the driver by looking at either /usr/src/linux/MAINTAINERS or the source for the driver itself (it'll probably be under /usr/src/linux/drivers/net/tokenring).
Token Ring is horribly sensitive to timing issues, especially when using Cat5 in a physical bus instead of a physical coax ring.
I have seen a TR network where a single machine could develop a problem, and this would cause a group of 8 machines to all lose the net. Any one of those machines could bring them all down, and the only thing that would get them back up was shutting them all off (completely power-down, even rebooting didn't do it) and then bringing them back up one by one. Something as simple as shutting down Windows NT to the "click to reboot" prompt was enough to cause the problem to develop; eventually one of them would lose it's mind, and they'd all go.
Throw into that mix, the fact that Linux Token Ring drivers are bastard stepchildren that get 1/1,000th of the use of the Ethernet drivers (if that much) and you end up with real problems.
Bottom line; come in a weekend and try that other NIC out, maybe it's drivers are more mature. But other than that, don't dick with the company network, Token Ring is too damn sensitive.
You might try putting a few NT boxes into the "click to reboot" state, and see if they screw up the company network too. Works best with 3COM TR NICs, which is ironic since they also seem to recover the best to having their cable pulled and replaced while live.
If they see the problem is Token Ring specific, and just exacerbated by a bad Linux driver, perhaps they'll switch to Ethernet. If they trade their TR NICs in to somebody like CablExpress, they might break even or make a small profit on the switchover, and they'll certainly recover the costs in a short period of buying Ethernet NICs instead of new TR ones; they're horribly expensive, and the infrastructure gear (CAUs, LAMs, MAUs, switches, routers, etc.) is even worse.
An even better suggestion might be to find a job in a shop that prefers the more-manageable problems of Ethernet to the problems of Token Ring.
...don't use Token Ring. It is such an astounding brain-damaged protocal its a wonder anyone ever started using it, and its blasphemous that anyone uses it today. Not to be rude, but your management must be full of complete morons if they are still using token ring.
---- I made the Kessel Run in under 11 parsecs.
Actually, back when I was doing Token Ring on a regular basis, there was a Win driver issue with madge TR nic's that would take a ring down.
Some how, some way, every madge nic on a particular ring would decide at almost the same time that it wanted to be the RPS (ring parameter server) and/or the active controller. Not a very nice thing on a large ring, nor is it easy to troubleshoot.
We eventually figured out the problem when (for the third time) we shut every machine on the ring down, and brought them up one by one. The machine that started having the problem changed every time, but every machine that started the problem had the same driver loaded. We replaced the cards with Olicom, got the current drivers, and never had that problem again.
Notice I didn't say never had A problem again. When Token Ring worked, it was fairly good... when it didn't, almost by design it was a pain in the (insert your choice here).
Anyhow, my 2%.
Sig??? I don't need no stinkin Sig!
Last time I had a problem with my Tolkien Ring it was a Nazgul. Fortunately I had a CSU/DSU handy to whack it upside the head with (made by Gandalf, of course - wouldn't have worked otherwise).
Yeah, I know, jokes like this are a bad Hobbit...
We have used Linux and Token Ring for years in our company network. Biggest problem has been to find a reliable drivers. We settled for Olicom adapters and their driver. The driver works under kernel version 2.2.19. We used it on our central CVS server with more than 50 users. Olicom has been bought by Madge the other non-IBM-producer of Token-Ring-Adapters.
/ ol icom/
/
We switched the whole network to 100 MBit Ethernet, so we will not look into the issue in the future.
The drivers in the kernel have some problems, particular for PCMCIA.
Here some useful links:
Linux Token-Ring page, with updated drivers, but a discouraging news entry from 9/14/2001:
http://www.linuxtr.net/
Linux-Software for Olicom-Drivers(recommended):
http://www.madge.com/connect/downloads/software
Linux-Software for Madge-Adapters on:
http://www.madge.com/Connect/Downloads/Software
It's not that uncommon at all to find some application that conflicts with some other application and floods the network with crap. Ditto for hardware.
Yes, in this case, Linux did get a bad rep, and it may have been deserved. It's a fairly safe bet that very few people use Linux with Token Ring, so the drivers probably haven't been very well tested.
If you're truly paranoid, do what another poster did and test in a limited environment. Unfortunately, doing this for every new piece of hardware and software added to the network (not just Linux stuff) would take *forever* so you need to trust that things will work at some point.
You should pull out your 'network protocol design books' and read up on the fundamental differences between token ring and ethernet. On a token ring network, each node plays an active part in passing the token. If one node is misbehaving, it _can_ seriously affect the rest of the network.
I ran Token Ring on my personal desktop and a server at work for over two years without any incidents requiring sysadmin intervention.
Here's how I did it:
So, it worked for me, as I said, for a couple of years. But then I moved to a new site with pure Ethernet, and I have to admit that life is much simpler now.
or maybe MS would get slammed because:
1) they destroyed America's free market for software;
2) there is no source code available so people could fix the driver.
I'd be suprised if this wasn't fixed pretty fast. That's the great thing about Linux...one of the things that always pissed me off about dealing with MS was various NT bugs that would just sit for years at a time.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
What I see here is that a lot of People no longer have a clue about Token ring - am I getting realy old (I am 25) ?
This is generally bad, because TR is realy a cool Technology (except that it was always to expensive and proprietary)
But superior technology was never the point.
(see also: Donalds Becker s comment on NE2000 clones)
The Network card is not the only possible error source. Token Ring is an active Network, where a lot of the logic is within the NIC and the Cabling (e.g. M(S)AU = Multi Station access unit)
All Stations are assembled in a physical double ring. Even though the Cabling is a star topology.
If you connect your station to a MAU (= TR hub)
your plug is connected to the MAU, but you are not yet connected to the ring. If you turn on your computer, the network driver opens a relay in the MAU (signaled via the adabter cable) to switch you into the ring.
If you turn off the computer you get discinnected.
All data on the ring passes all the NICs in the ring (exception: Early Token Release). The NC acts as a Bridge (it amplifies the signal to the next ring segment).
Since the unamplified distance between to NCs is limited this can lead to the "Token Ring Sleeps at Night" Problem, where the token Ring refused to work at night (simply because too many employes turn off there PC after work)
This can simply be overcome by replacing passive MAUs with active TR Switches.
One should also have in mind, that the cable to the network card is a part of the ring after activation of the card. A faulty cable can disturbe the ring (even though it should be automaticaly removed from the ring)
I would try your laptop directly on a TR switch.
Thís way you can eliminate driver/TR component interaction (a driver which agressivly tries to connect to a ring with a faulty cable)
I personaly implemented many Linux Servers with linux and never had problems with disturbing ring operation. I used IBM and Olicom Adabters and they always worked well.
Oh please.
And then an informed reader would point out that the driver was provided by the manufactorer, not Microsoft. Thus, Microsoft itself would have little direct involvement in this case.
A more reasonable Open Source advocate might chip in that an open source driver would provide a faster path to hunting down and fixing the problem (Source is available for this driver, though I don't know what the license is - so that point may or may not be tested in this case).
There is mindless zealotry all over the tech industry, media, and public forumns. It goes far beyond Slashdot and Linux. Please try to refrain from adding to it.
You do have a way out: use the IBM card. It was working a few years ago, and I imagine it's still working today. Yes, you do have to patch the kernel--what's the problem with that?
If that's not to your liking, you can throw money at the problem and buy a TokenRing/Ethernet bridge and use an Ethernet card on the Linux machine. Maybe your managers will see the light and convert more of your network to Ethernet.
In general, TokenRing is dead technology. Many operating systems just don't support it at all anymore. How long should Linux carry the burden of supporting outdated and flaky technologies?
I work with broken... sorry, Token Ring every day. I work for a state agency with near 5,000 nodes (server, workstation, printer, etc) which until just last year were all on TR. The switch has only just started to Ethernet and going office by office as budget allows.
/.'ers out there?)
I came from an all Ethernet environment prior to the this job and have had some experience with ARCNet as well. (Hows that for you old
Token Ring is a logical ring topology, ususally implemented in a physical star or bus topology. Some of our rings have upward of 200 nodes with thousands of feet of cabling connecting them. We have MAU's (Multiple Access Units - a hub) connected to each other with copper and fiber. Most of the cabling that runs to the workstations is type I - 4 conductor, big gauge stuff that comes to large data connectors at the wall. If you haven't seen these, you'd love them, about 1 1/4" square and 2 1/2" long. Then a lobe cable goes to a db-9 connector on the NIC card.
TR works by passing a token (electrically) to each node in sequence. When a node has data to be transmitted, it hangs the data on the token and sends it on it's way. All subsequent cards check to see if the data is for them and then pass it all on if it's not. The intended recipient strips the data and sends the token on it's way. In a 4Mb ring, there is one token and on a 16 Mb ring there are two, 180 deg. to each other (timing-wise) on the ring. I don't know how the 100 Mb version does it, but almost nobody uses that.
This has an advantage in that there are no such things as collisions like on Ethernet. This allows for the massive number of nodes per ring and high efficiency in data transfer - perhaps 80 - 90% For comparison, Ethernet starts having problems due to collisions at 40% or so - depending on the number of nodes.
It also has the disadvantage that a single break at any point in the ring breaks the whole ring. (Think Christmas lights in series rather than parallel.) Another disadvantage is exactly the problem the poster reports - timing errors. I don't know if the problem was just timing errors, but the other problem - beaconing - would have brought the whole ring down right away and he said that it was was just noise with the potential to bring the ring down.
Indeed, timing is critical. Beacon errors are worse as the NIC put out spurious signal that doesn't allow any node to hear the token as they attempt to pass it around.
Early in my employment, I attempted to put a linux box on the ring, but couldn't get the TR drivers to work with a Madge or old IBM card. About a year in, they got all tight-assed and concerned about security and prohibited all alternate OS's. We're an all M$ house, how's that for irony. Security, what security? At least we're behind a pretty good firewall.
As far as the problem with this particular installation, I agree with other posters who have said that the author of the driver needs to be contacted to report the bug and maybe get a fix. It would be good to set up a separate ring with just the two nodes (and the fluke) to try to ID the problem. But he may also be facing administrative/political issues as well. Those are hard to overcome, especially in a large organization, and even more in a government agency - as I have found.
I'm not karma whoring, I just thought that since this technology (TR) is so ancient and in use by so few places, readers unfamiliar with it might like a little info.
BTW, the aforementioned ARCNet is also a token passing design that runs on a bus or a star and runs at 2 Mb. It can run on UTP or 93 ohm coax (RG-62) It's relatively robust, if slow. A boss of mine went to a Novell Admin class where the instructor hooked a server and workstation together on ARCNet with BNC connectors crimped to a piece of barbed wire. It passed data acceptably.
Hope this all helps a bit.
War is Peace. Freedom is Slavery. Ignorance is Strength. - George Orwell or George Bush?
...and your post helps this guy out how?
This is obviously a vendor driver problem, not a Microsoft or Linux problem.
Having the source *does* help, but that, again, is up to the vendor.
How does an obviously offtopic troll post get moderated up to 5? There appears to be a lot of freebasing going on amongst the moderators today...
The promised reliability never materialized. In the early days, the TR connector was the same as that for DB9 serial ports and EGA (pre-VGA) video. L-users would frequently connect the cables incorrectly, taking down the entire LAN. In the later days, 10BaseT Ethernet replaced coax, and became slightly more reliable than Token Ring. These days, we used switched Ethernet, which is infinitely more reliable than Token Ring.
Keeping Token Ring networks running has become like voodoo management. Stories like yours are common. Nobody knows exactly WHY things are going wrong, so they are quick to point the finger at oddball stuff. There is so little support for Token Ring that nobody can figure out how to solve even basic problems. The only solution is to remove the offending products from the network.
Here is some background for what might be going wrong. First of all, your card has its own microprocessor. As a kid in the early 1980s I owned a TI-99/4a home computer/game-console: it is roughly the same CPU in your card. It runs its own embedded OS. This means that under normal conditions, your card will run fine, regardless of the driver: all the intelligence is on the adapter, not in the driver.
I point this out because you never specified exactly the types of errors you are receiving. In theory, all such errors are related to the hardware, and there is nothing the driver can do to cause them. Specifically, I don't know how it can be possible for something to "cause ring errors that eventually bring down the entire net". There are really no progressive failures like this in Token Ring.
If you mentioned the precise ring error and/or the method in which the ring goes down, it might be helpful. Here are some possible ring erors.
A burst-error is caused when an adapter inserts itself into or removes itself from the ring. This might be caused because, for some reason, Linux might be re-initializing the card. For example, you may have DHCP set to renew the lease every minute which may cause this to happen. I have no knowledge of how Linux deals with Token Ring, but if the problem is "Burst Errors", then it is because of some higher-layer interaction like this.
A "receiver congestion" error is caused when the Linux driver doesn't remove packets from the card's buffers fast enough. In theory, they are suppose to indicate that packets are coming in too fast for the machine to handle. In practice, you see this happen when machines "hang" and fail to empty their queues. You might be running some sort of libpcap packet-sniffer on the system or have the adapter running in promiscuous mode (do an ifconfig to check) that is having some sort of pathelogical condition.
Maybe you are getting "FC errors" which indicate that somebody has the same MAC address as you. This won't happen if you use the standard MAC address built into the card, but it could happen if the Linux driver has a bug setting a locally administered address. Maybe it's setting it to all zeroes, causing a conflict with some other card that has a similar bug.
None of these errors really cause problems. Burst errors will nuke a frame as it passes by (maybe one out of a thousand) -- the hardware auto-retransmits, so it doesn't cause performance problems. Receiver congestion errors only cause problems for YOU and nobody else on the ring. A duplicate address will only cause problems with the other machine that shares your MAC address.
My guess is that your admins are just getting testy over the fact that your Linux box re-inserts itself more often than Windows boxen, causing a higher number of relatively harmless burst-errors. When they diagnose problems with the ring, they notice that your machine causes the highest number of errors, and therefore blamr any ring failure on you.
If your machine is truly causing a problem, the only thing I can think of is that your port on the hub gets "stuck" (this happens a lot). The process of re-inserting has a small chance of getting stuck, so if your Linux box re-inserts 100 times more often than Windows, you'd see this.
BTW, Token Ring is a good lesson in Zen. A burst-error is defined as 5 half-bit times without a transition. What this really means is that a station has entered or left the ring. I point this out because if you try to debug this problem yourself, you'll have to hunt down Token Ring references. Go quickly to the definition of burst-errors: if it has the "technical" definition, discard the reference and move on. If it has the "practical" definition, then you'll be in luck.
One ring to rule them all, One ring to find them.
One ring to bring them all and in the darkness bind them.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
Um, how about posting the actual "ring errors" that your lan admins were seeing. Also, did you try contacting Madge, since they supply the card and drivers? I'm still not really sure why this is an Ask Slashdot. While I'm sure it's within the realm of possibility that an errant (or improper configuration of a) driver hosed the network (an ex-admin of ours hosed our network with the linux box after he was let go), there isn't much detail here, there are many mailing lists devoted to this kind of thing, and your hardware vendor does support your card under linux. From their website:
yada yada. The fact that you posted this as an Ask Slashdot (and the complete lack of details), make me question the veracity of this report. Regardless, if this did happen, it is too bad. People at your work will undoubtedly have a bad impression of linux from this. Such is life.-no broken link
What's more, TR has collision avoidance built into the protocol, where Ethernet networks have to be architected in star topologies to avoid collision, because Ethernet responds horribly.
However, TR is horribly inefficient when one machine produces a disproportionate amount of traffic (which is the case for pretty much all corporate networks). Unless each machine in your ring produces a steady stream of packets, the old ALOHA collision model still wins.
Linux does token ring really well if you use the right adapters.
We have token ring adapters of all types. I've found the newer IBM PCI TR adapters to work best. They use the "olympic" driver included with the kernel. I have 6 Linux machines at work using these drivers and they've performed flawlessly... except when someone unplugs the cable. In that case, the box needs a reboot, but the rest of the network is fine.
I first tried the IBM PCI LanStreamer but couldn't get it to last more than a few minutes. I'm guessing there's a problem with the buffers that freezes up the interface. I tried one of the newer Olympic cards on a whim, and haven't looked back.
If you have REALLY ancient equipment, the Tropic-based 16/4 TR Adapter/A (long and short version) is known to work on Microchannel machines. I've put together one of these and had it running as a TR-to-ethernet router for a while.
All this stuff can be gotten on eBay or elsewhere for dirt cheap.
I haven't tried the Madge or Olicom cards, but we have plenty of IBM cards, so I've stuck with those.
+++
NO CARRIER
Believe it or not, I used to work for a company that manufactured "1-hour photolab" equipment, and many of those systems STILL use ARCNet internally for all the different components to talk to each other.
It may sound arcane, but it's robust, interference resistant, cheap (I guess), and reliable. If you're not passing tons of data, it works just fine.
MadCow.
I used to have a sig, but I set it free and it never came back.
No. I'll qualify that. It's vile.
Theoretically, TokenRing is wise, clever, fault-tolerant and the *only* way to get your LAN running close to ultimate bandwidth.
I *like* TokenRing. In theory.
In practise, it sucks. Specifically, it sucks *all* the bandwidth out of your network.
A healthy TR network *will* use all the bandwidth that it needs. Collisions are impossible.
Then, a node fails (which is what happened to you). Gradually, the overhead of regenerating tokens becomed an issue. Remember, a node will *never* regenerate a token unless it is convinced that it's up-ring node is dead or bonkers. However, if the upstream node has gone totally doolally, the one downstream will regenerate.
Regeneration is *good*. except that the upring node is spewing filth onto the ring. So, the regenerated token is lost in garbage. Guess what happens next?
Yes! the next node tries to regenerate.....
Identifying this is easy. Find the node that is still operating. Then, find the nearest axe, and apply it with enthusiasm. Amazingly, the LAN recovers within seconds.
I still bear the scars of a TR network that failed. We split it every way we could. Eventually, we we took the server with the borked ISA bus (feeding the NIC) out of the loop.
All I can say is *GET THAT BOX OFF THE LAN* You are pissing people off with it. That is *not* good for Linux.
I would say "rewrite the network drivers", but that's pointless. Say sorry (repeatedly) and advocate Ethernet. I'd rather have collisions than catastrophes...
Token ring was often more reliable than Real Ethernet Thick-wire with Vampire Taps - the mechanical connectors were better than just chomping your way into a coax cable with the possible risk of trashing the code enough to get reflections. I'm not sure if it was better than connectorized thinwire or not, and it certainly wasn't better than Cat5 10baseT, at least if you used genuine Cat5 and didn't cheat with Cat3 (or didn't use cable-TV coax instead of proper thinwire :-) Back when I used to deal with this awful stuff, I had one customer for whom the original Ugly Shielded Twisted Pair token-ring really did make sense - they were a city's Department of Water and Power, and they had lots of Really Big Electric Motors which were a really bad electrically noisy environment, and their network needed all the help if could get. These days I hope they're using fiber.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Oh fergawdsakes, will this urban legend ever die!
It simply isn't true.
Shut up, be happy. The conveniences you demanded are now mandatory. -- Jello Biafra
Oh fergawdsakes, will this urban legend ever die!
It simply isn't true.
Actually, it is true... Under ethernet, the more nodes you put in a collision domain (this is layer 2, not to be confused with a layer 3 _broadcast_ domain), the more likely a collision, the more time is spent recovering from collisions. The exact 40% depends on how many nodes are on the segment and how much info they have to send and how often, but 40% is in the ballpark for when problems start to appear
There is a very simple (and not very expensive nowadays) way to get around this problem: use switches in place of hubs. A switch creates a two node collision domain (the switch and the end node). In fact, when full duplex is enabled (only possible with switches for an obvious reason) the collision detection is turned off.
The result: no collisions and thus you can get even more efficient than token ring (no token to wait for).
Do you actually have any stats to the contrary? My numbers show about 30% actually.
I've never had a 10/T segment with more than 5 computers active get any more than 2-3Mbps in backplane bandwidth.
With a switched hub, yes, you get full bandwidth between each port (assuming the hub has sufficient backplane bandwidth to deal with all the inter-port traffic), but with normal "old-fashioned" ethernet hubs, no, you don't.
- Michael T. Babcock (Yes, I blog)
This happens with ethernet as well. I've seen this many times over the years (and even within the past month) -- a single machine spewing packets faster than any router can process, a bad port in a switch turning everything in broadcast traffic, trunking misconfigurations spewing uncomprehensible junk to workstations, unstable etherchannel configurations...
Not greater truth has been written about Token Ring!
ttyl
Farrell
CAN-CON 2019 - Ottawa's only book oriented Science Fiction Convention! October 18-20, Sheraton Hotel, Ottawa, Canada h
It sounds very much like you're trying to insert into the ring at 4mbps on a 16mbps ring or vice versa. That will freak out other things on the ring pretty badly. I know of successful Olicom usage, but I always used an IBM PCMCIA Token Ring 16/4 card. Check your ring speeds.
a good network design should not allow this to happen in the first place. If a client is sending incorrect commands to the network or is eating up the token, etc, the router should cut off that node's access to the network
A router is just another node on a token-ring - it can't do the stuff you're talking about in the general case. If some broken-ring adaptor screws up, the router is typically just as baffled as anyone else. token-ring is over-complicated, over-costly nonsense. With really cheap switched ethernet available, no new network should ever use it, and old networks should migrate, as new NICs and hub costs will eat you alive.
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
Interestingly, the 'bug open for years' syndrome also affected proprietary Unixes - you would find the same bugs across all the different Unixes in some cases (particularly in command line tools), although in some ways bug portability was a help, as you knew what to expect.
Some bugs only affect a tiny minority of people, just like some 'orphan diseases' that may affect only tens of people world wide. Along with bugs that are perceived as trivial, such bugs sometimes get very little attention from a vendor, for commercial reasons. Some vendors are better than others, particularly small vendors for whom any customer is pretty important, or those with good contact with their users (e.g. some shareware vendors). A key benefit of open source is that it tends to bring users into closer contact with developers, and of course users can just become developers (or hire a developer) to fix problems.
This looks like something that happened a few years ago where I was working.
If the driver sets the card to 4MBits (The token ring cards have different speeds) the whole ring will pop into 4 Mb/s and the ring will crash as a result.
It was at a
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
My last company used to have a Token Ring network. THey had the same problem if an IBM PS/2 was brought up on the network at 4Mbps and not 16Mbps. In short it would bring down the entire network.
I did not view this as a PC problem, but an inherrent problem with Token Ring, so I moved that the company should migrate to Fast Ethernet, and low and behold they did.
That was the end of that particular problem.
I used to work for the major AS400 software house in the UK and had a lot of dealings with token ring (and Twinax!!) and we found the major cause of network issues was the type of card.
Madge cards do not like working in an environment with IBM cards (okay they have sorted things out a wee bit, but it still isn't perfect) because IBM token ring cards run to lower timing tolerances. This is fine where all other cards on the ring accept this, but Madge cards are designed to much higher specifications and easily start beaconing if the previous/next card round the ring is off on its timing.
Your best bet is to get hold of those IBM drivers and use an IBM card - and go for a test environment for a wee while too:)
The canonical reference is: Measured Capacity of an Ethernet: Myths and Reality.
Note particularly that Van Jacobson was able to obtain measured TCP throughput of 8Mb/s in the 80's.
There is a good review of the area in the O'Reilly book on Ethernet too.
The limit of five Tolkien rings can be a problem for large corporate empires. And adding a new ring can be quite a quest.
I was involved as a consultant some years ago (ca 1996) with the decision of a college to migrate from TR to ethernet. At the time the situation was very cloudy; TR was clearly on the way out, but there was some question as to whether we should go FDDI or CDDI or perhaps ATM for the network backbone. I recommended the use of Ethernet throughout the system. Ethernet,in its most primitive an naive implementations, has a number of problems when used as a basis for a large network. The answer, of course, is not to use it primitively or naively.
Ethernet evolved from networking schemes used for packet radio. The original idea was you had a single medium (a long cable) that was shared by a number of hosts. As in radio, they were supposed to listen before talking (Carrier Sense Multiple Access/Collision Detection or CSMA/CD) so they didn't garble each others' messages (collisions).
CSMA/CD networks have two problems: (1) throughput begins to collapse somewhere between 40% and 50% of the nominal speed due to collisions and retransmissions and (2) packets delivery cannot be guaranteed within a fixed time (although at low loads latencies tend to be very low).
However, Ethernet switching technology has taken care of the througput problem by reducing the number of machines sharing a medium for purpose of collision detection, to the point where a single workstation on a full duplex switched port can never have a collision. A combination of switches with huge backplane capacity, spanning tree, trunking, VLAN and powerful routers give the administrator great flexibility in delivering network capacity to every port on his network, along with excellent scalability.
The only thing that remains is guaranteed delivery times for packets; although stations needn't worry about collisions, there is still queuing time within the switches to consider. This might affect people attempting to stream broadcast quality video over their network to several workstations, who might choose to go with 100Mbit token ring. In theory QoS is supposed to address this, but I haven't seen it used much. Most streaming media applications are Internet centric, and buffer their data to prevent problems due to the much more random nature of the Internet. It is possible to contrive scenarios where you need QoS or isochrounous packet delivery (e.g. high quality video conferencing over a LAN) but these haven't proved to be very important. If they were, then ATM would probably be a better choice than TR.
Of course TR still has to be supported for places that have too much human inertia to switch, but I don't think there is any technology that is superior to Ethernet in its cost effectiveness for the widest range of corporate applications.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Then you need the network admins to either assign you a subnet, or you have to deal with NAT... and you have an extra box.
Ethernet QoS is rarely deployed, but that's largely because there is less need for QoS in the LAN - most switches and links have more capacity than they really need, so as you point out only videoconferencing, VoIP and other non-streaming multimedia really need QoS.
Many Ethernet switches support 802.1p (a priority field within the 802.1Q VLAN header), allowing basic prioritisation. The larger L3-aware switches also support IP Precedence or even DiffServ (e.g. the Catalyst 6500). In the longer term, as policy-based management becomes more widely deployed, it's likely that switches will have 802.1p turned on, largely to support VoIP (since that is actually being deployed on some networks).
This, of course, is more of a LAN than a WAN point.
Given the ubiquitous nature of Token Ring, this should have been caught during pre-alpha.
cat