---------------------------------------------------------------------- ETHRvsTR.DOC -- 19970304 -- Email thread on Ethernet versus Token Ring ---------------------------------------------------------------------- Feel free to add or edit this document and then email it back to faq@jelyon.com [Consider] ETHERCAP ZIP 167092 07-14-94 Boggs, Mogul, Kent "Measured Capacity of an Ethernet: Myths and Reality", DECWRL 88/4 found in directory misc on netlab2.usu.edu. TRN saturates lower because one station sending still must wait for token rotation to occur. Joe D. ------------------------------ Date: Thu, 4 Jan 1996 21:38:18 -0800 From: rgrein@halcyon.com (Randy Grein) To: netw4-l@bgu.edu Subject: Re: Two network Cards >>While I've seen some network jocks excessivey proud of >>their ability to manage an overloaded LAN, I doubt that IBM would be >>employing that strategy at a critical facility. > >Proud...? >There is no pride in beeing able to manage a overloaded LAN. >I see it more as a survival-skill while fighting cost-minded managers. >On the other hand beeing able to handle a 'ready to crash'-LAN is >a skill from which you can benifit every now and then. My point exactly. Sometimes you can get farther by saying "No!", as long as it doesn't cost your job. >Correct me if I'm wrong but isn't Ethernet capable of handling *huge* >short bursts while token ring would simply collaps, meanwhile trying >to get the token back on line? I do like Token Ring. Great concept, >but in practise and compared to Ethernet it just doesn't seem to get >the job done. Not really. Ethernet is faster than 4 meg token ring, but the big advantage is that it was designed to be routable from the beginning; that and it's much less expensive. Oh, and let's not forget the switching issue. Ethernet switches are easy; token ring switches are just coming out now. On lightly loaded networks ethernet can still be faster, as it doesn't have to wait for the token to pass around again, but even under short bursts of traffic 16 mb TR is faster. Just not by much. Considering the time and money spent keeping things running at high utilizations, I'd opt for more and faster everything. If you include labor costs (including the cost of replacing burned out administrators) it's usually much less expensive to spend the money up front. ------------------------------ Date: Mon, 8 Jan 1996 06:17:44 -6 From: "Mike Avery" To: netw4-l@bgu.edu Subject: Re: Two network Cards >Correct me if I'm wrong but isn't Ethernet capable of handling *huge* >short bursts while token ring would simply collaps, meanwhile trying >to get the token back on line? >I do like Token Ring. Great concept, but in practise and compared to >Ethernet it just doesn't seem to get the job done. OK. You're wrong. My previous employer used Token Ring, and it was far more stable than Ethernet. A poor cable plant can cripple any topology, as can excessive loads. But, once you have lost control over load management Token Ring will cope far better than Ethernet. Ethernet under 10BaseT is a vast improvement over COAX, however it is still not as stable as Token Ring. In a WAN with 19,000 nodes at over 400 sites using Token Ring, we had less than 6 outages that extended past 1/2 day due to cable faults in 5 years. At my present gig, Ethernet, even with new cabling and good hubs, has fared less well. A major, as yet undiscussed, advantage of Token Ring is that it is deterministic. This allows predictions of performance to be reliably made.... but more importantly, it assures everyone of some level of performance. My predecessor at this job cabled a number of Dec workstations onto the same Ethernet Segment as a number of low power PC's. When the Dec's start to hammer the net, the PC's don't stand a chance of getting any traffic through. The timing windows are too short. We have since moved the PC's to different segments, and the PC users are MUCH happier. With Token Ring, that would not have been necessary. Of course, that begs the question of price. It is probably cheaper to do Ethernet right than to do a Token Ring installation. However, there are times when the installation cost is not that large a part of total life cycle costs. ------------------------------ Date: Wed, 10 Jan 96 00:43 MET From: arthur-b@ZeelandNet.nl (Arthur B.) To: netw4-l@bgu.edu Subject: Re: Two network Cards >> Correct me if I'm wrong but isn't Ethernet capable of handling *huge* >> short bursts while token ring would simply collaps, meanwhile trying >> to get the token back on line? >> I do like Token Ring. Great concept, but in practise and compared to >> Ethernet it just doesn't seem to get the job done. > >OK. You're wrong. Can't be always right. >My previous employer used Token Ring, and it was far more stable than >Ethernet. A poor cable plant can cripple any topology, as can >excessive loads. But, once you have lost control over load >management Token Ring will cope far better than Ethernet. Depends on the amount of load and the number of active connections. IMHO. >Ethernet under 10BaseT is a vast improvement over COAX, however it is >still not as stable as Token Ring. I find Token Ring to be better in technical perspective. >In a WAN with 19,000 nodes at over 400 sites using Token Ring, we had >less than 6 outages that extended past 1/2 day due to cable faults in >5 years. Describe 'cable faults'. >At my present gig, Ethernet, even with new cabling and good hubs, has >fared less well. What were the problems? >A major, as yet undiscussed, advantage of Token Ring is that it is >deterministic. This allows predictions of performance to be reliably >made.... but more importantly, it assures everyone of some level of >performance. My predecessor at this job cabled a number of Dec >workstations onto the same Ethernet Segment as a number of low power >PC's. When the Dec's start to hammer the net, the PC's don't stand a >chance of getting any traffic through. The timing windows are too >short. We have since moved the PC's to different segments, and the >PC users are MUCH happier. With Token Ring, that would not have been >necessary. IMHO Token Ring is not 'collision aware'. That means that if something goes wrong (token gets stuck) and other stations are creating new tokens (with different time-intervals) you can get into trouble when does start crashing into eachother. Now you can argue that Token Ring doesn't need to detect collisions, but when something goes wrong on Ethernet is will take action upon that fact, while Token Ring will simply keep trying. The part of the timing windows I do not understand. If all comply to the electrical specs you shouldn't have a problem when connecting them to the coax. At least I will found out in the near future when the Novell UTP gets connected to a DECnet coax. If you're right I will have problems *grin* >Of course, that begs the question of price. It is probably cheaper >to do Ethernet right than to do a Token Ring installation. However, >there are times when the installation cost is not that large a part >of total life cycle costs. IMHO the same amount of money will get you more value for money when you choose for Ethernet instead of Token Ring. I have seen before that admins spoke of dreadfull Ethernet while actually refering to some cheapo coax that was trown together while comparing it with their high-tech neatly laid out Token Ring. And don't forget. There is more to find for Ethernet (hardware/software) then for Token Ring. So, because of price and choice I would go for Ethernet (UTP, then Coax) most of the time. ------------------------------ Date: Wed, 10 Jan 1996 00:19:13 -0800 From: rgrein@halcyon.com (Randy Grein) To: netw4-l@bgu.edu Subject: Re: Two network Cards >>A major, as yet undiscussed, advantage of Token Ring is that it is >>deterministic. This allows predictions of performance to be reliably >>made.... but more importantly, it assures everyone of some level of >>performance. My predecessor at this job cabled a number of Dec >>workstations onto the same Ethernet Segment as a number of low power >>PC's. When the Dec's start to hammer the net, the PC's don't stand a >>chance of getting any traffic through. The timing windows are too >>short. We have since moved the PC's to different segments, and the >>PC users are MUCH happier. With Token Ring, that would not have been >>necessary. > >IMHO Token Ring is not 'collision aware'. That means that if something >goes wrong (token gets stuck) and other stations are creating new tokens >(with different time-intervals) you can get into trouble when does >start crashing into eachother. > >Now you can argue that Token Ring doesn't need to detect collisions, >but when something goes wrong on Ethernet is will take action upon >that fact, while Token Ring will simply keep trying. > >The part of the timing windows I do not understand. >If all comply to the electrical specs you shouldn't have a problem >when connecting them to the coax. > >At least I will found out in the near future when the Novell UTP gets >connected to a DECnet coax. > >If you're right I will have problems *grin* Hi Arthur! What he's talking about is protocol dependent. See, TCP/IP depending on the part of the stack involved (TCP is actually a whole family of protocols) can 'burst' a series of packets out before requiring an acknowlegement packet. By tailending a series of packets together, you can do two things: 1. improve workstation response tremendously 2. improve bandwidth utilization slightly While I won't second guess the situation too much, I can say that I've seen the problem before. With mismatched workstations on a segment, the faster machines will hog all the available bandwidth under ethernet, particularly if: The driver/adapter combination is breaking the quiet time rule - it's supposed to wait a standard ammount of time after it either sends or detects a packet, and in the quest for speed some manufactures have been violating it - as revealed by Bob Metcalfe about 2 years ago. The problem only seems to occur under heavy loads, but boy was he mad when he found out what they'd done to "his baby"! The disparate workstations are not optimized for conditions. It's not that hard reconfigure to throttle back the window openings to allow other traffic to get through, but it does require a complete understanding of both the protocols used and ethernet - just as optimizing token ring requires a similar level of expertise. Seldom is one individual equal with both. >>Of course, that begs the question of price. It is probably cheaper >>to do Ethernet right than to do a Token Ring installation. However, >>there are times when the installation cost is not that large a part >>of total life cycle costs. > >IMHO the same amount of money will get you more value for money when >you choose for Ethernet instead of Token Ring. >I have seen before that admins spoke of dreadfull Ethernet while >actually refering to some cheapo coax that was trown together while >comparing it with their high-tech neatly laid out Token Ring. A good point. I think market share pretty much speaks for itself here. ------------------------------ Date: Wed, 10 Jan 1996 20:25:55 -6 From: "Mike Avery" To: netw4-l@bgu.edu Subject: Re: Two network Cards >>>A major, as yet undiscussed, advantage of Token Ring is that it is >>>deterministic. This allows predictions of performance to be reliably >>>made.... but more importantly, it assures everyone of some level of >>>performance. My predecessor at this job cabled a number of Dec >>>workstations onto the same Ethernet Segment as a number of low power >>>PC's. When the Dec's start to hammer the net, the PC's don't stand a >>>chance of getting any traffic through. The timing windows are too >>>short. We have since moved the PC's to different segments, and the >>>PC users are MUCH happier. With Token Ring, that would not have been >>>necessary. >>IMHO Token Ring is not 'collision aware'. That means that if something >>goes wrong (token gets stuck) and other stations are creating new tokens >>(with different time-intervals) you can get into trouble when does >>start crashing into eachother. Token ring doesn't need to be collision aware, because there are no collisions under token ring. When you get the token, you speak. Otherwise you remain silent. No collisions. As to losing the token, if there is a malfunction, the active ring monitor will detect the fact that the token has been lost, usually in about 60 to 80 milliseconds, and issue a new token. If the problem that caused the token to be lost also took out the active ring monitor, then the secondary ring monitors will negotiate to see who will become the new active ring monitor. Then that device will issue a new token. The negotiation is fairly quick. >>Now you can argue that Token Ring doesn't need to detect collisions, >>but when something goes wrong on Ethernet is will take action upon >>that fact, while Token Ring will simply keep trying. I could argue that your statement doesn't make a lot of sense. I could reverse the phrasing just as easily. When something goes wrong on Ethernet, it will simply keep trying, while token ring will take action upon that fact. It seems that "taking action" and "simply keep trying" mean about the same thing. >>The part of the timing windows I do not understand. The DEC machines are much faster than the low end PC's and were able to detect the end of traffic and jump on the network much more quickly than the PC's. Or so it seemed. While there were were about 40 DEC machines and 80 PC's, about 95% of the traffic was DEC traffic. Some users were complaining because from the time they typed enter after "login name" it was over 5 minutes before they were presented with a password request. The difference between the performance they saw and "dead" was very minimal. >What he's talking about is protocol dependent. No, not at all. This is topology dependent, and a question of loading and the fundamental access mechanism. CSMA/CD was not able to tolerate the load that was being presented to it, and insure reasonably equitable distribution of resources. >See, TCP/IP depending on the part of the stack involved (TCP is >actually a whole family of protocols) can 'burst' a series of >packets out before requiring an acknowlegement packet. With PBURST, IPX can do the same thing. However, the question is one of how media access is granted, not what one does with it. >While I won't second guess the situation too much, I can say that I've seen >the problem before. With mismatched workstations on a segment, the faster >machines will hog all the available bandwidth under ethernet, particularly >if: >The driver/adapter combination is breaking the quiet time rule - it's >supposed to wait a standard ammount of time after it either sends or >detects a packet, and in the quest for speed some manufactures have been >violating it - as revealed by Bob Metcalfe about 2 years ago. The problem >only seems to occur under heavy loads, but boy was he mad when he found out >what they'd done to "his baby"! That describes the situation pretty well. In a discussion long ago and far away on FIDONET, an aquaintance had a new person join their shop. Since she had moved from an ethernet to a token ring environment, my aquaintance asked which was faster. His new co-worker thought about it and summed it up as well as I have ever heard it summed up : "Token Ring is never as fast as Ethernet - or as slow." A friend who is a board designer at Thomas Conrad grinned when he heard that. He commented that the implementation of Token Ring is years behind Ethernet, and that it will speed up. Another tid-bit. Token Ring is not being taken full advantage of under NetWare. The president of Thomas Conrad once said in an interview that at it's core, NetWare assumes Ethernet, and treats all topologies as though they were Ethernet. It took me about a year to find out what he meant. Under token ring, each packet makes the all around the network, and back to the originator. When the intended recipient sees the packet, it toggles a bit on the end of the packet, commonly called the "seen by" bit. If the packet is read successfully, it also toggles the "read by" or "copied" bit. (I may have the name on that wrong. But it means that the packet has been dealt with.) If these bits were honored by the NetWare drivers, the ack packets would not be required under token ring. Unless PBURST is activated, each packet generates an acknowledgement. This ties up a fair anount of bandwidth and time. Look at a sniffer or lanalyzer trace... about 1/2 the packets are about 64 bytes. Most of them are ack packets. I suspect that routers would have to be a bit more intelligent to allow networks to take advantage of this - generating an ack packet when bridging between ethernet and token ring for example. >>>Of course, that begs the question of price. It is probably cheaper >>>to do Ethernet right than to do a Token Ring installation. However, >>>there are times when the installation cost is not that large a part >>>of total life cycle costs. >>IMHO the same amount of money will get you more value for money when >>you choose for Ethernet instead of Token Ring. >>I have seen before that admins spoke of dreadfull Ethernet while >>actually refering to some cheapo coax that was trown together while >>comparing it with their high-tech neatly laid out Token Ring. >A good point. I think market share pretty much speaks for itself here. Market share is a fickle [thing], at best. OS/2 had serious advantages over Windows.... Motorola's CPU's have always been better than Intel's.... Betamax was better than VHS. I think you can provide your own examples to continue the theme. Market share means that a product has sold more than it's competitors. It may suggest superiority, but it is not proof of it. (If you still don't get the point, let me point out that there are more people who do not share your religous beliefs {whatever they are} than those who do.) But as to the point about life cycle costs, when the last place I worked made the decision to go with Token Ring the choice was between coax based ethernet and token ring. The 10baseT variation was not yet available. My own feeling, from having worked on several large lans, is that token ring is orders of magnitude more stable than coax based ethernet. The number of failures that can impact more than one user are fewer in number and lower in probability than with coax based ethernet. Token ring is easier to troubleshoot, and it is easier to isolate problems. And that is a major part of the life cycle costs. How much does down time cost? It keeps people from doing their jobs, it ties up your technical staff, and it hurts your reputation. If you look at a 10baseT implementation, the reliability is quite similar to that of token ring, but the price difference has eroded somewhat. A name brand ethernet card, plus a Cabletron or Synoptics hub port are not cheap. Yes, many people do compare a poorly laid out ethernet coax system to token ring. I suspect that is in part because coax is physically fragile, and that most cable plants do deteriorate. So, the manager who compares them went from the headaches of a bad coax plant to a the calm of a new token ring installation..... and sees no reason to go back. Getting back to market share, it is sometimes easier to sell something different to ones management than to sell an improvement. "So, let me understand this.... our problem is ethernet, and you want to solve it by buying ethernet?" "Yes, but the old ethernet was coax and the new ethernet will be utp!" Right..... this is the manager who has trouble setting the clock on his VCR.... As a closing comment, I should invite Gordon Peterson into this discussion. I think that topology debates are a waste of time - they all have their strong points and their weak points. People who insist on one true topology are missing the point. But Gordon was one of the designers of ARCNet, and is a true evangalist. He'll try to get us all to rip out our ancient topologies and convert to the topology of the future, ARCNet. And he'll make a darn good case too. ------------------------------ Date: Wed, 10 Jan 1996 21:11:55 -6 From: "Mike Avery" To: netw4-l@bgu.edu Subject: Re: Two network Cards >Ethernet is happy up to 50-70% utilization, token ring starts degrading at >70-80%. Hmmmm.... the guys at Thomas Conrad suggest that in most situations that when you pass about 30% utilization attempts to do more of what you've been doing only result in increased contention, collisions, and overhead. While that will show as utilization on a line monitor, it won't show up as improved performance on any benchmarks. The maximum practical utilization of any topology is a pretty fluid sort of number. It depends on what you are doing, with how many nodes, and so on. >While I can't prove it, I'm skeptical of the 99-100% utilization claim. Truthfully, so am I. I asked the vendor for a visit, and he said he'd give us a tour. 2 1/2 years later, I'm still waiting for details to be firmed up. I somehow suspect that I won't be getting the tour - or a look at the pegged line monitor. ------------------------------ Date: Thu, 11 Jan 1996 00:37:16 -0800 From: rgrein@halcyon.com (Randy Grein) To: netw4-l@bgu.edu Subject: Re: Two network Cards >>See, TCP/IP depending on the part of the stack involved (TCP is >>actually a whole family of protocols) can 'burst' a series of >>packets out before requiring an acknowlegement packet. > >With PBURST, IPX can do the same thing. However, the question is one >of how media access is granted, not what one does with it. > >>While I won't second guess the situation too much, I can say that I've seen >>the problem before. With mismatched workstations on a segment, the faster >>machines will hog all the available bandwidth under ethernet, particularly >>if: > >>The driver/adapter combination is breaking the quiet time rule - it's >>supposed to wait a standard ammount of time after it either sends or >>detects a packet, and in the quest for speed some manufactures have been >>violating it - as revealed by Bob Metcalfe about 2 years ago. The problem >>only seems to occur under heavy loads, but boy was he mad when he found out >>what they'd done to "his baby"! > >That describes the situation pretty well. >Under token ring, each packet makes the all around the network, and >back to the originator. When the intended recipient sees the packet, >it toggles a bit on the end of the packet, commonly called the "seen >by" bit. If the packet is read successfully, it also toggles the >"read by" or "copied" bit. (I may have the name on that wrong. But >it means that the packet has been dealt with.) If these bits were >honored by the NetWare drivers, the ack packets would not be >required under token ring. Unless PBURST is activated, each packet >generates an acknowledgement. This ties up a fair anount of >bandwidth and time. Look at a sniffer or lanalyzer trace.... about 1/2 the >packets are about 64 bytes. Most of them are ack packets. > Thanks for the education on TR, I don't do enough to be quite as technical as I'd like, however: This isn't a "netware" problem, it's a fundemental layering problem. TCP/IP functions in the same way. If you're required to get an acknowlegement packet, simply flipping a bit on the frame won't do. Or rather, it would serve as an acknowlegement, but it functions at the wrong layer. It's faster, it's simpler. It's a very clever idea that conserves bandwidth wonderfully, but you CAN'T route that type of acknowlegement. Heck, you can't even bridge it. As we live (most of us, anyway) outside of a 1-ring world, this just won't wash. Too bad, really. I'd heard that TR had some wonderful features that just plain were never used, but hadn't heard what they were. >I suspect that routers would have to be a bit more intelligent to >allow networks to take advantage of this - generating an ack packet >when bridging between ethernet and token ring for example. Think about it for a moment. An intermediate device had better not be claiming delivery for a packet just because IT handed it off. No guarenteed delivery, don't you know. And if you then require acknowlegement passed back from every intermediate router, the traffic generated would kill the network. >Market share is a fickle bitch, at best. OS/2 had serious advantages >over Windows.... Motorola's CPU's have always been better than >Intel's.... Betamax was better than VHS. I think you can provide >your own examples to continue the theme. Market share means that a >product has sold more than it's competitors. It may suggest >superiority, but it is not proof of it. (If you still don't get the >point, let me point out that there are more people who do not share >your religous beliefs {whatever they are} than those who do.) I was simply pointing out that for most people, it was more cost effective (the primary justification cited, at least) to select ethernet rather than TR. It wasn't that long ago, after all, that TR cards were nearly as pricey as FDDI! >But as to the point about life cycle costs, when the last place I >worked made the decision to go with Token Ring the choice was between >coax based ethernet and token ring. The 10baseT variation was not >yet available. My own feeling, from having worked on several large lans, >is that token ring is orders of magnitude more stable than coax based >ethernet. Then I would have agreed with you. Thin ethernet, after all has a distance span of 185 meters and 32 devices. However, it's been 6 years of 10Base-T, or 3 hardware generations. A long time for everything except physcal plant. TODAY is a different story. >The number of failures that can impact more than one user >are fewer in number and lower in probability than with coax based >ethernet. Token ring is easier to troubleshoot, and it is easier to >isolate problems. And that is a major part of the life cycle costs. >How much does down time cost? It keeps people from doing their jobs, >it ties up your technical staff, and it hurts your reputation. >If you look at a 10baseT implementation, the reliability is quite >similar to that of token ring, but the price difference has eroded >somewhat. A name brand ethernet card, plus a Cabletron or Synoptics >hub port are not cheap. Try $60-$99 per card, ISA or PCI, and about $5-600 for managed 16 port hubs. WITH backbone connectors, but I'd hesitate to place too many in series. If you want big, managed, PRICY boxes, it'll cost a bit more, but I'd never limit myself to just Cabletron or Synoptics, cause I don't like paying Porche prices for Ford performance. >Yes, many people do compare a poorly laid out ethernet coax system to >token ring. I suspect that is in part because coax is physically >fragile, and that most cable plants do deteriorate. So, the manager >who compares them went from the headaches of a bad coax plant to a >the calm of a new token ring installation..... and sees no reason to >go back. Of course. It doesn't matter that he made the right decision (rip out the old stuff) for the wrong reasons (he's afraid there's something wrong with ethernet), does it? My point here is education, not evangelism. >As a closing comment, I should invite Gordon Peterson into this >discussion. I think that topology debates are a waste of time - they >all have their strong points and their weak points. People who >insist on one true topology are missing the point. But Gordon >was one of the designers of ARCNet, and is a true evangalist. >He'll try to get us all to rip out our ancient topologies and convert >to the topology of the future, ARCNet. And he'll make a darn good >case too. Mike, what's wrong with Arcnet? Nothing other than it ultimately lost out in the market races! Too bad, cause some of the new stuff at the end was pretty amazing. Let's face it, in 5 years we'll be using 100 baseT, VG Anylan, ATM or maybe even something high speed that works! As we start migrating, we'll all have to understand the new stuff, deal with integrating it into the existing systems, work on new and better routers and switches, and maybe even have time for lunch. If we are to make intellegent decisions on topology, methods and madness we'll need to understand what we're using now as well as the options. Otherwise we become the rather foolish manager you mention, making reactive decisions based on luck alone. ------------------------------ Date: Thu, 11 Jan 1996 00:37:30 -0800 From: rgrein@halcyon.com (Randy Grein) To: netw4-l@bgu.edu Subject: Re: Two network Cards >>>In a WAN with 19,000 nodes at over 400 sites using Token Ring, we >>>had less than 6 outages that extended past 1/2 day due to cable >>>faults in 5 years. >> >>Describe 'cable faults'. > >Broken cables, disconnected cables, that sort of thing. When the >cables are in the walls, it can be hard to find the bad spot. Worst >case was one time when a GDC vendor decided to use the MSAU's that >some bozo had stacked on the floor as a stepping stool to reach his >modems. (GDC, BTW is General DataCom. Usually a good bunch of >people.) He slipped and disconnected about 20 cables, damaging a >number of them. The staff on site fumbled the problem for a while. >In the end, we had them trace all the cables, then they found the >break. The kept falling into the "if it worked yesterday, and it >doesn't work today, then there is A problem, and when we find and fix >it, all will be well" mental trap. Mike, you're not describing differences in topology so much as cable management! That's why there's standards for wiring now! Even with coax, if you're playing the "just stuff the cable into the ceiling, and drop it into each office" game of course it will come out like crap. Token ring won't play in that field much better, and the only reason it does it the MAU. If TR had a bus topology, you'd have the same problem. >>>At my present gig, Ethernet, even with new cabling and good hubs, >>>has fared less well. >> >>What were the problems? >All sorts of odd little things. Once we convinced the purchasing >department that we REALLY did need a UPS on the hubs, things got >better. Same thing here; you're not comparing like to like at all! Power problems will kill any network. ------------------------------ Date: Thu, 11 Jan 1996 00:37:35 -0800 From: rgrein@halcyon.com (Randy Grein) To: netw4-l@bgu.edu Subject: Re: Two network Cards >>Ethernet is happy up to 50-70% utilization, token ring starts degrading at >>70-80%. > >Hmmmm.... the guys at Thomas Conrad suggest that in most situations >that when you pass about 30% utilization attempts to do more of what >you've been doing only result in increased contention, collisions, >and overhead. While that will show as utilization on a line monitor, >it won't show up as improved performance on any benchmarks. I don't buy it, I've seen different on my own tests as well as others. Think about it - at 30% the likelyhood is that most of the time the wire is quiet, so few collisions. The only real overhead is collision packets which are tiny - so it would take a LOT of collisions to impact bandwidth. Of course, each workstation was so much slower that users would notice, and probably complain, and you DO have a statistical likelyhood of timing out. Server backbone traffic seems to fair a bit better, and I'm thinking that it's probably also a statistical issue - with fewer devices there's less chance of collisions. Maybe time to break out my rather rusty statistical math toolkit! >The maximum practical utilization of any topology is a pretty fluid >sort of number. It depends on what you are doing, with how many >nodes, and so on. > >>While I can't prove it, I'm skeptical of the 99-100% utilization >>claim. > >Truthfully, so am I. I asked the vendor for a visit, and he said >he'd give us a tour. 2 1/2 years later, I'm still waiting for >details to be firmed up. I somehow suspect that I won't be getting >the tour - or a look at the pegged line monitor. Don't you just hate that? ------------------------------ Date: Thu, 11 Jan 1996 07:39:10 -6 From: "Mike Avery" To: netw4-l@bgu.edu Subject: Re: Two network Cards >>>>In a WAN with 19,000 nodes at over 400 sites using Token Ring, we >>>>had less than 6 outages that extended past 1/2 day due to cable >>>>faults in 5 years. >>> >>>Describe 'cable faults'. >> >>Broken cables, disconnected cables, that sort of thing. When the >>cables are in the walls, it can be hard to find the bad spot. > >Worst case was one time when a GDC vendor decided to use the >MSAU's that some bozo had stacked on the floor as a stepping stool >to reach his modems. (GDC, BTW is General DataCom. Usually a >good bunch of >people.) He slipped and disconnected about 20 >cables, damaging a number of them. The staff on site fumbled the >problem for a while. In the end, we had them trace all the cables, >then they found the break. The kept falling into the "if it >worked yesterday, and it doesn't work today, then there is A >problem, and when we find and fix it, all will be well" mental >trap. Mike, you're not describing differences in topology so much >as cable management! That's why there's standards for wiring now! >Even with coax, if you're playing the "just stuff the cable into >the ceiling, and drop it into each office" game of course it will >come out like crap. Token ring won't play in that field much >better, and the only reason it does it the MAU. If TR had a bus >topology, you'd have the same problem. A bus topology is a major problem. But as to the discussion of cable plants and cable faults, the fact of life is that you will have problems. The next question is what will the topology do to help minimize the problem? In the case of coax based ethernet, the answer is nothing. Any number of cable faults will bring down the entire segment. And since there is no central point of reference, then you are stuck chasing the cable from node to node. I used to teach a class in a community college that was using coax. They made the jump to 10baset.... a number of students had found that they could put a single break in the coax and watch the technicians scramble for an hour trying to find the problem - and that they didn't have to take the on-line tests. In the case of token ring, most node problems affect only that node. (You can get into trouble if you get the data wires cut but not the relay energizing wires. That has happened to me about 3 times in 19,000 nodes over 6 years - twice at the site where the GDC rep helped us.) And single breaks in the ring-in ring-out chain are self healing. >>>>At my present gig, Ethernet, even with new cabling and good hubs, >>>>has fared less well. >>> >>>What were the problems? >> >>All sorts of odd little things. Once we convinced the purchasing >>department that we REALLY did need a UPS on the hubs, things got >>better. > >Same thing here; you're not comparing like to like at all! Power >problems will kill any network. Passive Token Ring hubs don't notice. Individual nodes will be dropped of the net when they lose power, but the net itself is unaffected. The bigger point is that you have to set up any topology correctly. If you have an active device, and you depend on it, it needs power protection. I'd be interested in finding impartial studies of token ring versus ethernet 10baset reliability, and life cycle costs. So far, I've seen none. Again, getting management interested in life cycle costs is sometimes a hard task. ------------------------------ Date: Thu, 11 Jan 1996 07:53:22 -6 From: "Mike Avery" To: netw4-l@bgu.edu Subject: Re: Two network Cards >This isn't a "netware" problem, it's a fundemental layering problem. TCP/IP >functions in the same way. If you're required to get an acknowlegement >packet, simply flipping a bit on the frame won't do. Or rather, it would >serve as an acknowlegement, but it functions at the wrong layer. It's >faster, it's simpler. It's a very clever idea that conserves bandwidth >wonderfully, but you CAN'T route that type of acknowlegement. Heck, you >can't even bridge it. As we live (most of us, anyway) outside of a 1-ring >world, this just won't wash. Too bad, really. I'd heard that TR had some >wonderful features that just plain were never used, but hadn't heard what >they were. I suspect there are other neat features, but like you, there is a limit to how deep I have time to delve. Your bridging point is very well taken, as are the difficulties of routing that sort of ack. It is worse than I thought. This makes me suspect that the president of Thomas Conrad had something else in mind with regards to his comment that NetWare treats all topologies as though they were ethernet. >>Market share is a fickle bitch, at best. OS/2 had serious advantages >>over Windows.... Motorola's CPU's have always been better than >>Intel's.... Betamax was better than VHS. I think you can provide >>your own examples to continue the theme. Market share means that a >>product has sold more than it's competitors. It may suggest >>superiority, but it is not proof of it. (If you still don't get the >>point, let me point out that there are more people who do not share >>your religous beliefs {whatever they are} than those who do.) > >I was simply pointing out that for most people, it was more cost effective >(the primary justification cited, at least) to select ethernet rather than >TR. It wasn't that long ago, after all, that TR cards were nearly as pricey >as FDDI! I missed out on those days. When I got into Token ring, we were paying about $600 per card, and FDDI was well over $2,000 per node. I can get token ring now, without doing serious shopping, for around $200 a node. FDDI, last time I looked, was still over $1,500. More if you want dual connect (and I think you probably do). >>But as to the point about life cycle costs, when the last place I >>worked made the decision to go with Token Ring the choice was >>between coax based ethernet and token ring. The 10baseT variation >>was not yet available. My own feeling, from having worked on >>several large lans, is that token ring is orders of magnitude more >>stable than coax based ethernet. > >Then I would have agreed with you. Thin ethernet, after all has a >distance span of 185 meters and 32 devices. However, it's been 6 >years of 10Base-T, or 3 hardware generations. A long time for >everything except physcal plant. TODAY is a different story. >>If you look at a 10baseT implementation, the reliability is quite >>similar to that of token ring, but the price difference has eroded >>somewhat. A name brand ethernet card, plus a Cabletron or Synoptics >>hub port are not cheap. > >Try $60-$99 per card, ISA or PCI, and about $5-600 for managed 16 port >hubs. WITH backbone connectors, but I'd hesitate to place too many in >series. If you want big, managed, PRICY boxes, it'll cost a bit more, but >I'd never limit myself to just Cabletron or Synoptics, cause I don't like >paying Porche prices for Ford performance. Sime managers insist on buying from the big guys. I don't agree, but it is a fact of life for me. And when that decision has been made, it is a cost consideration. My hub port prices are kinda high as a result. In a few locations I've been able to sneak in cheap unmanaged hubs - like the segment where all my email servers are. It's 10 feet from my office, I walk by it regularly, and the phone will be a better alarm system than an SNMP system. >Mike, what's wrong with Arcnet? Nothing other than it ultimately lost out >in the market races! Too bad, cause some of the new stuff at the end was >pretty amazing. Let's face it, in 5 years we'll be using 100 baseT, VG >Anylan, ATM or maybe even something high speed that works! The biggest problem with ARCNet was 2.5mbps. A bit too slow for today's nets. Even if it is 99% available. I used it at home for a while. Now I have a coax based ethernet. (I think coax is fine under some conditions. Like less than 10 nodes in a cooperative environment. My home LAN qualifies.) Even though ARCNet is clean, easy to setup and manage, and damn near never breaks, I can no longer recommend it. ------------------------------ Date: Thu, 11 Jan 1996 07:59:46 -6 From: "Mike Avery" To: netw4-l@bgu.edu Subject: Re: Two network Cards >>>Ethernet is happy up to 50-70% utilization, token ring starts degrading >>>at 70-80%. >>Hmmmm.... the guys at Thomas Conrad suggest that in most situations >>that when you pass about 30% utilization attempts to do more of what >>you've been doing only result in increased contention, collisions, >>and overhead. While that will show as utilization on a line monitor, >>it won't show up as improved performance on any benchmarks. >I don't buy it, I've seen different on my own tests as well as others. >Think about it - at 30% the likelyhood is that most of the time the wire is >quiet, so few collisions. The only real overhead is collision packets which >are tiny - so it would take a LOT of collisions to impact bandwidth. It also depends on what you are doing. When Ethernet was designed, it was intended to support Unix machines. Lots of little packets. And the 30% figure comes from studies done on those systems. The guy I talked to at Thomas Conrad made some more comments that I am just now remembering (age is a terrible thing... the memory is the second thing to go.... I forget what the first one was). Under NetWare there is a "meta-layer" of handshaking. A node makes a request of the server and waits for a reply. This allows higher useage under NetWare than would be feasible under a peer to peer Unix system. With mutiple applications making and replying to requests... the classic ethernet net has very different traffic patterns from NetWare nets. Again, the number of nodes is an issue. With a smaller number of nodes, higher levels of traffic are workable. ------------------------------ Date: Thu, 11 Jan 1996 23:26:34 -0800 From: rgrein@halcyon.com (Randy Grein) To: netw4-l@bgu.edu Subject: Re: Two network Cards >A bus topology is a major problem. > >But as to the discussion of cable plants and cable faults, the fact >of life is that you will have problems. The next question is what >will the topology do to help minimize the problem? > >In the case of coax based ethernet, the answer is nothing. Any >number of cable faults will bring down the entire segment. And since >there is no central point of reference, then you are stuck chasing >the cable from node to node. I used to teach a class in a community >college that was using coax. They made the jump to 10baset.... a >number of students had found that they could put a single break in >the coax and watch the technicians scramble for an hour trying to >find the problem - and that they didn't have to take the on-line >tests. Agreed, and a long time ago. So why the continued discussion of coax? Nobody on the ethernet side of this ahs suggested it as an option! >> Same thing here; you're not comparing like to like at all! Power >> problems will kill any network. > >Passive Token Ring hubs don't notice. Individual nodes will be >dropped of the net when they lose power, but the net itself is >unaffected. Whoops! Got me there! I hadn't considered passive hubs, Don't think I've ever seen one - even at the federal offices I've worked at. >The bigger point is that you have to set up any topology correctly. >If you have an active device, and you depend on it, it needs power >protection. > >I'd be interested in finding impartial studies of token ring versus >ethernet 10baset reliability, and life cycle costs. So far, I've >seen none. Again, getting management interested in life cycle costs >is sometimes a hard task. I'd like to see that study, too, although I think it's a little late. The more useful study would be a real comparison between 100Base-T (Lousy as much of anything except to the desktop) 100VG, FDDI and ATM (Almost There, MA!). And of course you're correct about proper setup and PLANNING. BTW, don't forget that everything you've said about coax ethernet were justifications for 10BaseT. Although, to be fair, the port isolation never seemed to work as well as TR does... . ------------------------------ Date: Thu, 11 Jan 1996 23:26:39 -0800 From: rgrein@halcyon.com (Randy Grein) To: netw4-l@bgu.edu Subject: Re: Two network Cards >I suspect there are other neat features, but like you, there is a >limit to how deep I have time to delve. Your bridging point is very >well taken, as are the difficulties of routing that sort of ack. It >is worse than I thought. This makes me suspect that the president of >Thomas Conrad had something else in mind with regards to his comment >that NetWare treats all topologies as though they were ethernet. Could be. Maybe he's still mad that people didn't pick up on the TCNS? >The biggest problem with ARCNet was 2.5mbps. A bit too slow for >today's nets. Even if it is 99% available. I used it at home for a >while. Now I have a coax based ethernet. (I think coax is fine >under some conditions. Like less than 10 nodes in a cooperative >environment. My home LAN qualifies.) Even though ARCNet is clean, >easy to setup and manage, and damn near never breaks, I can no longer >recommend it. Yea, arcnet would be OK to attach a printer to, or for shop floor controls. Impervious to EMF, and you can span 5 miles without a bridge or router! Just too damn slow anymore. Of course, if Novell can deploy this power line networking they're pushing for low speed networking, just imagine... ! I'm using Coax ethernet at home, too, same reasoning. The kids are beginning to agitate for a second mac, however, so maybe I'll break down and do real wiring this summer. Thanks for the perspectives! ------------------------------ Date: Thu, 11 Jan 1996 23:26:45 -0800 From: rgrein@halcyon.com (Randy Grein) To: netw4-l@bgu.edu Subject: Re: Two network Cards >>I don't buy it, I've seen different on my own tests as well as others. >>Think about it - at 30% the likelyhood is that most of the time the wire is >>quiet, so few collisions. The only real overhead is collision packets which >>are tiny - so it would take a LOT of collisions to impact bandwidth. > >It also depends on what you are doing. When Ethernet was designed, >it was intended to support Unix machines. Lots of little packets. >And the 30% figure comes from studies done on those systems. Could be. Could also be with those small packets they were running into problems with routing/bridging/servers keeping up. The big reason for all the packet forwarding statistics in router/bridge comparisons is just that. The new silicon is much faster. And of course, if you're routing 64 byte packets it'll swamp your router at much lower figures than 1.5 k data transfers. >The guy I talked to at Thomas Conrad made some more comments that I >am just now remembering (age is a terrible thing... the memory is the >second thing to go.... I forget what the first one was). > >Under NetWare there is a "meta-layer" of handshaking. A node makes a >request of the server and waits for a reply. This allows higher >useage under NetWare than would be feasible under a peer to peer Unix >system. With mutiple applications making and replying to requests... >the classic ethernet net has very different traffic patterns from >NetWare nets. This is largely correct, but again it's not just Novell, it's standard Networking practice. Under TCP/IP, if you use UDP packets, no acks are specified, but the upper layers of the stack will insist on receiving acknowlegements, and if you're using a connection-oriented protocol such as oh, say FTP, the protocol itself handles sending and receiving ack packets. Its just that IPX had a "single packet, single ack return" configuration until they implemented burst mode; TCP/IP had this solved from the beginning. ------------------------------ Date: Fri, 12 Jan 1996 23:49:37 -0800 From: rgrein@halcyon.com (Randy Grein) To: netw4-l@bgu.edu Subject: Re: Two network Cards >>What he's talking about is protocol dependent. See, TCP/IP depending on the >>part of the stack involved (TCP is actually a whole family of protocols) >>can 'burst' a series of packets out before requiring an acknowlegement >>packet. By tailending a series of packets together, you can do two things: >> >>1. improve workstation response tremendously >>2. improve bandwidth utilization slightly > >Aha! This makes it a whole lot clearer for me. Thanks. >Is this somewhat like what RIP does between routers? Not really. RIP (Router Internet Protocol) sends route update info between routers. This is identical to the ability with TCP to send multiple packet during data transfer, and reply with a single acknowlegement. >>While I won't second guess the situation too much, I can say that I've seen >>the problem before. With mismatched workstations on a segment, the faster >>machines will hog all the available bandwidth under ethernet, particularly >>if: > >With mismatched you mean with non-default time settings (waittime, etc.)? >Or, default time settings that aren't accoording to international specs? I meant workstations with mismatched capabilities - faster nic, cpu, or inefficient drivers - anything that would make one machine significantly faster than another. Think of it something like drivers merging onto a busy freeway - the timid, slow ones will have a hard time getting on unless everyone behaves courtiously, whereas the bold, fast drivers will have no trouble barging into whatever lane they want. >>The driver/adapter combination is breaking the quiet time rule - it's >>supposed to wait a standard ammount of time after it either sends or >>detects a packet, and in the quest for speed some manufactures have been >>violating it - as revealed by Bob Metcalfe about 2 years ago. The problem >>only seems to occur under heavy loads, but boy was he mad when he found out >>what they'd done to "his baby"! > >Are you saying that Digital is somewhat violating the specs? ;) I'm saying they might be. >>The disparate workstations are not optimized for conditions. It's not that >>hard reconfigure to throttle back the window openings to allow other >>traffic to get through, but it does require a complete understanding of >>both the protocols used and ethernet - just as optimizing token ring >>requires a similar level of expertise. Seldom is one individual equal with >>both. ------------------------------ Date: Sun, 14 Jan 96 23:56 MET From: arthur-b@ZeelandNet.nl (Arthur B.) To: netw4-l@bgu.edu Subject: Re: Two network Cards Did some investigation into the subject 'Token Ring - Ethernet'. What I didn't think of before is that some of us life in the US and some of us life in other countries. For me, that would be Holland. Seems the hardware and support you can get in the US for Token Ring is better then in Holland (maybe some Dutch readers disagree, but a few years ago I had to look into this matter and find that there wasn't much choice in suppliers and supportgroups). So my practical experience with Token Ring has been limited to some dreadfull cases (in other works, I have never seen a good working Token Ring, only troublesome ones). Back to Ethernet versus Token Ring: In the last couple of days we have been watching a discussion about it that was getting technical and technical by the day (IMHO). Not that I mind that but I like to do a 'Redo from start', maybe to see if I can still follow it all. :) 1. I argued that Token Ring isn't 'collision aware' and that you risk getting your ring hung up 'because of that'. Well, I was fastly reminded that Token Ring isn't collision aware and indeed it isn't. What I mean is the following: If the token is lost (token is handled by an Active Monitor on a single node with the highest address on the ring) the AM should build a new one after purging the ring. All the other nodes have the role of Standby Monitor and monitor if the AM is doing the job right. Suppose the AM hangs. As I understand it one SM should become the new AM. How do they do that? Well, they randomly choose a time-interval and try to become the new AM after that. This way there should allways be one SM that is the first and thus becomes the new AM because the other ones aren't trying to become the new AM at *that exact moment*. I argued that this isn't allways the case because I have seen that happen several times (some SM's tried to become the new AM at the same moment forever and ever.) Because of the discussion I now think that this was just a simple matter of bad configuration (just as some DECs claiming the entire coax for there one and leaving nothing to the PCs ;) 2. Ethernet coax-errors are harder to seek then on a Token Ring. So taking the costs of downtime Token Ring is more cost efficient. There is now question about that. Coax-errors are harder to find then errors on a star-network. But it's not that hard (begin at the server, place a terminator at the first tap, check the wire, go to the next tap, place a terminator...). You'll find it soon enough. And the change of such a failure is very low. Besides, when you have found the error you place a new piece of cable between the two taps. With Token Ring you find the error much faster but then you probarly have to replace one wire out of a bundle of wires. So you're downtime is lower *if* there is an bad cable. However, there are other costs too, see below. 3. Overall Token Ring costs less, mainly because it provides you with less downtime and better performance. In the short run maybe. In the long run, no. I'll explain. A term 'long cycle costs' was used. This is one of my points also. I believe Token Ring will die out (I have seen this happen with MCA and Betamax) and replacing a whole Token Ring network with an Ethernet one will cost you dearly. And before that happens you have extra costs (take Betamax for example, try buying a tape for it or have it repaired. And what about adding some fancy hardware to it?) IBM PS/2 MCA is another example. I know back then it seemed smart advicing to buy that kind of computer (I did in fact), however, we know see that MCA didn't make it. In fact, those of us that did bought them where allmost forced into buying complete new PC's (it was getting harder and harder to buy MCA aware hardware, not to mention the price of the stuff). In general, joining the big club will cost you less in the long run (except for Windows 95/96/97 *grin*). 4. Token Ring can handle heavy loads much better. Yes. But with Ethernet you can see that coming and you can do 'load balancing'. It will cost you, but not that much. So in practise, comparing two networks with equal budgets, the one with Ethernet can do a lot of 'load balancing' before he reaches the price that the Token Ring costed. In general I can compare this Token Ring - Ethernet discussion with MCA versus ISA. Compared to ISA MCA is better in many aspects. However, since MCA is just a small peace of the market not to many people where developing new hardware/software for it. That resulted in high prices, not to many experts that could help you troubleshoot your problems, staying behind on new technologies, no support for it on new hardware, etc. Today not so many people use MCA... ------------------------------ Date: Sun, 14 Jan 1996 21:13:48 -0500 (EST) From: kraushar@interport.net (Mo Kraushar) To: netw4-l@bgu.edu Subject: Re: Two network Cards >Back to Ethernet versus Token Ring: >In the last couple of days we have been watching a discussion about >it that was getting technical and technical by the day (IMHO). >Not that I mind that but I like to do a 'Redo from start', maybe to >see if I can still follow it all. :) > >1. > I argued that Token Ring isn't 'collision aware' and that you risk > getting your ring hung up 'because of that'. > Well, I was fastly reminded that Token Ring isn't collision aware and > indeed it isn't. >What I mean is the following: >If the token is lost (token is handled by an Active Monitor on a single >node with the highest address on the ring) the AM should build a new >one after purging the ring. >All the other nodes have the role of Standby Monitor and monitor if the >AM is doing the job right. Suppose the AM hangs. As I understand it one >SM should become the new AM. How do they do that? Well, they randomly >choose a time-interval and try to become the new AM after that. This >way there should allways be one SM that is the first and thus becomes >the new AM because the other ones aren't trying to become the new AM >at *that exact moment*. I argued that this isn't allways the case >because I have seen that happen several times (some SM's tried to >become the new AM at the same moment forever and ever.) >Because of the discussion I now think that this was just a simple >matter of bad configuration (just as some DECs claiming the entire >coax for there one and leaving nothing to the PCs ;) I dont think that's the way it works. rather an active monitor is selected based on sm with hiest max address. (try killing the m you'll find the same sm is always elected!) mo kraushar ------------------------------ Date: Sun, 14 Jan 1996 18:52:17 -0800 From: rgrein@halcyon.com (Randy Grein) To: netw4-l@bgu.edu Subject: Re: Two network Cards Hi Arthur! >1. > I argued that Token Ring isn't 'collision aware' and that you risk > getting your ring hung up 'because of that'. > Well, I was fastly reminded that Token Ring isn't collision aware and > indeed it isn't. >What I mean is the following: >If the token is lost (token is handled by an Active Monitor on a single >node with the highest address on the ring) the AM should build a new >one after purging the ring. >All the other nodes have the role of Standby Monitor and monitor if the >AM is doing the job right. Suppose the AM hangs. As I understand it one >SM should become the new AM. How do they do that? Well, they randomly >choose a time-interval and try to become the new AM after that. This >way there should allways be one SM that is the first and thus becomes >the new AM because the other ones aren't trying to become the new AM >at *that exact moment*. I argued that this isn't allways the case >because I have seen that happen several times (some SM's tried to >become the new AM at the same moment forever and ever.) >Because of the discussion I now think that this was just a simple >matter of bad configuration (just as some DECs claiming the entire >coax for there one and leaving nothing to the PCs ;) What you're seeing here is that it's possible to break ANY system; TR is no exception. Likely causes are: Cable distance/specs exceeded, defective MAU, or defective NICS. The end result would be similar to a stuck ethernet tranceiver, where the tranceiver keeps broadcasting packets endlessly, effectively taking down the net. Rare, but does happen. >2. > Ethernet coax-errors are harder to seek then on a Token Ring. > So taking the costs of downtime Token Ring is more cost efficient. >There is now question about that. Coax-errors are harder to find then >errors on a star-network. >But it's not that hard (begin at the server, place a terminator at the >first tap, check the wire, go to the next tap, place a terminator...). >You'll find it soon enough. And the change of such a failure is very low. >Besides, when you have found the error you place a new piece of cable >between the two taps. With Token Ring you find the error much faster but >then you probarly have to replace one wire out of a bundle of wires. >So you're downtime is lower *if* there is an bad cable. >However, there are other costs too, see below. > ANY bus based technology will have more downtime with greater difficulties in diagnostics, but I'll address the coax/10BaseT issues later. >3. > Overall Token Ring costs less, mainly because it provides you > with less downtime and better performance. >In the short run maybe. In the long run, no. I'll explain. >A term 'long cycle costs' was used. This is one of my points also. >I believe Token Ring will die out (I have seen this happen with >MCA and Betamax) and replacing a whole Token Ring network with >an Ethernet one will cost you dearly. And before that happens you >have extra costs (take Betamax for example, try buying a tape for >it or have it repaired. And what about adding some fancy hardware >to it?) IBM PS/2 MCA is another example. I know back then it >seemed smart advicing to buy that kind of computer (I did in fact), >however, we know see that MCA didn't make it. In fact, those of us >that did bought them where allmost forced into buying complete >new PC's (it was getting harder and harder to buy MCA aware hardware, >not to mention the price of the stuff). >In general, joining the big club will cost you less in the long run >(except for Windows 95/96/97 *grin*). TR isn't likely to die out suddenly, the installed base is too great. Much more likely that we'll evolve, gradually updating segment by segment to Fast Ethernet/VG Anylan/ATM/Whatever's hot. At this juncture I'd hesitate to recommend anyone lock themselves into a technology, the situation is too unstable. >>Yes, many people do compare a poorly laid out ethernet coax system to >>token ring. I suspect that is in part because coax is physically >>fragile, and that most cable plants do deteriorate. So, the manager >>who compares them went from the headaches of a bad coax plant to a >>the calm of a new token ring installation..... and sees no reason to >>go back. >Personnaly, I would kick the person that laid done the 'coax plant'. >I have seen a lot of coax in my life, I know of a lot of 'coax plants' >and never was there any trouble with the coax itself. >The only time I have seen trouble with coax was when someone connected >380 V to ground. What I don't understand here is that consistently through this thread we keep coming back to ethernet on coax - thin ethernet, presumably. Ignoring everything else for the moment, why? I haven't seen an enterprise coax network for some time; is it different elsewhere? If so, I'd have to agree - TR, because of the star topology and physical isolation provided by the MAU, beats thin ethernet hands down in an enterprise network, but for MOST systems 10BaseT affords the same reliability/isolation advantages that TR has, plus having lower costs and a much larger pool of trained technicians capable of solving most any problem that comes up. So, are we talking any ethernet, Thin ethernet, Thick ethernet or 10BaseT here? Also, what about wiring standards? Are we refering to any cheap wire thrown in or a certified cable plant that adheres to the guidelines? ------------------------------ Date: Tue, 25 Jun 1996 09:59:18 -0600 From: Joe Doupnik Subject: Re: 10BaseT maximum length >>10BaseT. According to the IEEE specs, 10BaseT shouldn't be longer >>than 100 metres. However I am informed that it is generally accepted >>to range between 100 - 150 metres depening upon the quality of the >>cable. > >You probably can run over 100M with 10B-T, but if you ever have a problem >with a hub, router, etc everyone is going to point to your out of spec >wiring as the culprit even though they may be the problem. I'd recommend >you stay in spec just to limit the finger pointing when things go wrong. > >>And that the range is based upon the signal loss in Db's >>(11.5db) maximum loss of source to destination. > >I believe that to be true. More importantly, to crosstalk, Near End Cross Talk, NEXT. >>And that CSMA/CD is not a limiting factor in UTP. Could someone please >>comment and explain. No relationship. >CSMA/CD is Carrier Sense, Multiple Access/Collision Detection. This is >related to the protocol (IPX/SPX) not topolgy you use (Ethernet). If you Very wrong. CSMA is a physical layer phenomena, not a protocol stack affair. Ethernet is a physical layer arrangement, and uses CSMA/CD, even if the CD occurs in the hub for 10BaseT wiring. >ran Token Ring over UTP that would be CSMA/CA (Carrier Sense, Mulitple >Access/Collision Avoidence) you could have a higher utilization of >bandwith before your network goes down. ...Your statement is true. Urban legend at work here. Joe D. ------------------------------ Date: Tue, 25 Jun 1996 15:57:51 -0600 From: Joe Doupnik Subject: Re: 10-BASE-T Maximum Length >>>And that CSMA/CD is not a limiting factor in UTP. Could someone please >>>comment and explain. >> >>CSMA/CD is Carrier Sense, Multiple Access/Collision Detection. This is >>related to the protocol (IPX/SPX) not topolgy you use (Ethernet). If you >>ran Token Ring over UTP that would be CSMA/CA (Carrier Sense, Mulitple >>Access/Collision Avoidence) you could have a higher utilization of >>bandwith before your network goes down. ...Your statement is true. > >CSMA/CD is a function of the Ethernet specification (media access method). >Token ring uses Token-passing, which is a different type of media access >than contention (of which CSMA/CD and CSMA/CA are examples). CSMA/CA is >used by AppleTalk and differs from CSMA/CD in that a RTS (Request to Send) >is sent after "sensing" the line. Once a CTS (Clear to Send) is received, >the data is sent. This doesn't, of course, *guarantee* that there won't >be a collision enroute! > >Debbie Becker What's more, Token Ring isn't a shared medium topology: it's point to point, daisy chaining points round the ring through a central controller, and passing that token packet from point to point. Token Bus is a logical ring over shared media, but few outside of industrial controller folks use Token Bus these days. Token Ring is a complicated affair, to put it mildly, when one gets down to the fine details. Hence the cost of boards implementing it. To thoroughly rot one's mind on these things have a careful look at HP's VG (voice grade) AnyLan mechanism (an IEEE standard, not 802.3, these days) which has many elements of a Token Ring from hub to hub, and isn't really Ethernet. It sort of looks like Ethernet to PC apps but it doesn't behave that way on the wire and hubs. The magic is in the hubs. OK CNE wannabes, here is a pop quiz for you: How can an ACK-ful protocol transfer files efficiently over Token Ring if the token represents "permission to speak on the wire?" That is, how can the receiving end reply with ACKs in a short time? Extra credit: what's route.vlm/nlm? Lab assignment/cheat sheet: run Lanalyzer for Windows on a Token Ring and see what happens. (Really desparate folks can [email] Laura Chappell at lchappell@imagitech.com and ask her). Joe D. -------- Date: Wed, 26 Jun 1996 13:59:55 -0600 From: Joe Doupnik Subject: Re: 10-BASE-T Maximum Length -Reply >> OK CNE wannabes, here is a pop quiz for you: >> How can an ACK-ful protocol transfer files efficiently over Token >>Ring if the token represents "permission to speak on the wire?" That is, >>how can the receiving end reply with ACKs in a short time? >> Extra credit: what's route.vlm/nlm? >> Lab assignment/cheat sheet: run Lanalyzer for Windows on a >>Token Ring and see what happens. (Really desparate folks can ring up >>Laura Chappell at >>Novell and ask her). >> Joe D. > >For those of us that read every message you post to the Novell list (we're >taking the non-credit version of the JRD networking course), but do not >have access to tolken ring (thankfully), could you post the answers to the >pop quizz? -------- There are two file transfer strategies, good and poor. The poor one is to wait for the token to arrive and send protocol ACKs. It's poor because token rotation time is not only irregular as all get out but it can be rather long. In a Stop and Wait protocol situation, where every data packet is acknowleged, throughput is zilch. But the receiver must toggle a bit in the rotating frame saying "I saw that!" and thus the sender gets notification of frame reception (not all that useful actually). The better situation is receipt of a packet entitles the recepient to one free transmission. That is, the arriving packet is changed to have the have-received bit set so the sender knows the packet arrived and can be removed from the ring (the sender has to do this, which becomes a fine art at times), and then the receiver gets to put a frame on the wire. The trouble with this is stupidity: we should never ACK arriving data until it has been delivered to the final destination, else the ACK lies and things do get lost. That ACK may take many many microseconds/milliseconds to achieve, just think of disk rotation delays, and that meshes poorly with token rotation and all that jazz. So the "good" situation has at most the "have-received-frame" bit to go on, and logical ACKs often get delayed until the token makes its way round the ring to the file receiver. As stated above, notification that a frame was received is in no way equivalent to a file transfer ok message (logical / protocol ACK). Thus "good" and "poor" look similar in real life. What covers up this fairly large time gap is a form of sliding windows in protocol traffic. But that's not used by all protocols. IPX doesn't do it unless Pburst is active, and Pburst is what I term jerking windows from all the very frequent stop and wait burst negotiations. SPX is worse, a very heavy packet exchanger, as folks with server based tape backup systems may have noticed. Keeping a ring small and not heavily used speeds up token rotation time (and makes a hash of TRN propaganda). Oh, what's route.nlm? It's the source routing helper for Token Ring. It strips out the route list from incoming frames, keeps them for each connection, and it inserts them into matching outgoing frames. Source routing is another of these not very bright ideas (trying to make a bridge behave similar to a router, and not succeeding, from the same folks who tried to foist 802.2 LLC fields upon us). Joe D. ------------------------------ Date: Wed, 26 Jun 1996 16:01:49 -0600 From: Joe Doupnik Subject: Re: 10-BASE-T Maximum Length >Good questions... route.com, route.vlm, route.nlm are used in an IBM >token ring environment when a source routing bridge is being used to >segment the network. At the workstation route.com or route.vlm >(netx or vlm issue) allows the workstation to participate in source >routing. At the server route.nlm does the same since each device in a >source routing environment is responsible for maintaining and creating >the routes to destination devices. > >I know I did the extra credit first but here goes on your main question: > >We may be looking at a difference in terminology but when you talk about >the "ACK-ful protocol" do you mean the ACK sequence number used in the >burst mode protocol or are you asking about the ACK flag in a TCP header? > >Craig Bodkin, CNI/CNE >Program Coordinator for IS >Trident Technical College ------------- Boy, don't try to fool a CNI! Correct answer. The ACK stuff means a response from the recepient that what was sent had been received, acted upon, and the status was success. To prevent delayed and repeated ACK packets from masquerading as ACKs to a current (later in time than the original sending) sent pkt we must attach sequence numbers to them. Sequence numbers guarantee that we detect holes (missing pkts) and duplicates, and they must be used in each direction for the same reasons. What is insufficient is to say "frame received ok here, thanks" and call it a day. Because there is a lot more to be done with the material. It's rather like the modem people saying why use checksums when we have these error correcting modems? Well, to answer briefly, no checksum is absolutely error free, and there's more to comms life than simulating copper wire. A disk-full situation is a simple example; the material arrives but can't be stored yet the transmission end thinks it was stored (disk caches, caching disk controllers, writing to disk without reading it back, etc all are similar in this regard). Software makes mistakes, yikes, and so on. Thus the ACK should be the delayed end to end "I've really done it" response. TCP headers have ACK fields (all data sent must be ACK'd, period). But that reflects only the protocol stack and not everything else in series. There is the real risk that data do not make it to the final destination, or suffer damage enroute. Joe D. ------------------------------ Date: Wed, 28 Aug 1996 15:55:26 -0600 From: Joe Doupnik Subject: Re: RE[2]: trying to play net.police >>>We are trying to charge our students for Internet use and I would >>>like to ask you for ideas / products on how to do that. --------- Here's my thinking on the Internet charging matter. If the Internet lines are paid for already but full (normal) then that's the bottleneck and the natural throttle. Improvments generally come from a fund affecting everyone on site, since everyone turns out to be the customers involved. To impose charges to develop free capacity says charging folks to create empty capacity they can't use. If the lines are not yet full then what's the problem? If there is a charge per packet or byte or similar then there is a clear relationship between use and expense, and to a degree (no pun) one can try to charge back such expenses. Customers might well argue that less should be charged during sluggish times since their own time is also worth something. To create funds for just using equipment is another more general matter, rather separate from the Internet. When the equipment and personnel and software exist already under other funding arrangments, as we expect, then imposing a tax to use it is double taxation. To pick out some uses rather than others to be taxed is an assumption of authority not normally delegated to service units. An analogy might be interesting here. Motor vehicle traffic. This month I was in two distant countries: England and Egypt. Traffic in Cairo is anarchy personified. No one paid the least attention to the few traffic lights and stop signs in town (13M people) nor to idle traffic wardens on the streets. People drove as fast as they could go. If a path were too crowded at times then other paths or times were used or guessed at. Surprizingly it worked very well indeed, and the traffic flowed smoothly and fast. Folks used the same algorithms to make judgements and the sharing was distributed down to the individual level, Ethernet style. Hitting something was bad news because it caused delays and expense, so the general agreement was to not ding things and pedestrians (who must play by the rules too); Carrier Sense in action. Expenses were minimized. England is installing photo boxes on many traffic lights which take a picture and send you a traffic ticket in the mail for committing any number of infractions, all without human intervention. Traffic does move, at a moderate pace, polite Token Ring style. There is some empty space on the roads, which must be one of the design criteria. There is a higher chance of getting through a particular roadway at any time than in Cairo. Needless to say, this is very expensive but does not make traffic go any faster. But the system is "highly managed" and therefore "good." I don't think this was put to a vote. So, in one case folks used up all the resource and waited for more road-width to make things better. In the other queueing was spread all over by gentle coercion, at substantial financial cost, while minimal service was assured. Joe D. ------------------------------ Date: Mon, 30 Sep 1996 14:13:32 -0400 From: Steve Kurz Subject: Re: Ethernet vs.TR Packet Burst >I'm teaching an elementary networking class at a junior college and >the book I'm using (Learning NetWare 4.1, Guy Yost, Que E&T) has >introduced an interesting question: > >True or False >Packet burst will benefit Ethernet networks more than Token-Ring >Networks. > >The answer in the back of the book is False, but with no explanation >through the text as to why. (How a student is supposed to correctly >answer this question is beyond me.) > >I thought it would be True due to the contention nature of ethernet vs >the more "equal sharing" nature of TR. I've checked several other >sources, but can not find any performance improvement comparisons. I guess it depends on the definition of "burst" If you look at Novell's packet burst, it is essentially a "stream of data packets" that is "saved" up to be transmitted all at once. The rate and size of the burst is dependent on the usage of the lan. The size of a packet of ethernet data is limited to 1510 bytes, and TR is 4202. If you consider that you can get more data out in a single burst on a TR network, the statement would be false. Also, since TR has a priority/reservation scheme, setting the reservation bit to exclusive could also be construed as a "burst". Just my opinion, your milage may vary. --------- Date: Mon, 30 Sep 1996 13:18:37 -0600 From: Joe Doupnik Subject: Re: Ethernet vs.TR Packet Burst [Original message question above repeated] ---------- There is no clear cut answer. Traffic patterns largely determine the throughput available. No one in their right mind turns on priority bits for normal work; it's another case of the Law of the Commons being invoked (or grade inflation in .edu land, or any number of grab and run schemes on NEWS, etc). Pburst simply tries to reduce the number of time intervals spent waiting for ACKs, but also uses time intervals negotiating them. It's a sticking windows approach, rather than say a sliding windows or pure stop and wait situation. Ethernet uses presence of other traffic plus a backoff algorithm to share access to the wire. Token Ring circulates a token (time limited permission to send) round all stations, whether or not they have anything to transmit. Both are "fair", both have gotcha's and advantages. One lets stations sort out matters amongst themselves, as they do remarkably well, the other "makes the trains run on time" (to go back in history about 60 years). Joe D. ------------------------------ Date: Tue, 17 Dec 1996 18:28:42 -0600 From: Joe Doupnik Subject: Where to ask Ethernet nuts&bolts questions Since we've gotten down to tiny little things (pins on RJ45 connectors) I thought some of you would like to know where all things Ethernet are discussed in detail (with some of the folks who wrote the specs). That place is NEWS group comp.dcom.lans.ethernet. There you can berate Rich Seifert for inventing the darned sliding clip on AUI connectors, and so on. Caution: here be tigers. Joe D. ------------------------------ Date: Tue, 4 Mar 1997 11:35:59 EST From: "Robert L. Herron" To: netw4-l@ecnet.net Subject: Re: Speed >I have a small netware 4.11 network with about 50 users. (Token-ring, 3 >netware servers, 1 NT, AS/400 etc.) The company have about 250 workers >and most are still on twinax. We are moving in about 5 months and I'm >networking everyone. > >The question is, which topology will give me faster performance. > > 1. A switch token ring backbone configuration. > 2. A switch ethernet, fast ethernet, switch fast ethernet config. > >I know that with ethernet, even though 100baset sounds exiting, the more >users the slower it becomes. I would install a hybrid network with switched Fast Ethernet and switched Ethernet. From my limited research (I looked in a couple mail order catalogs before reponding), Fast Ethernet is less expensive than Token Ring and gives you additional bandwidth. --------- Date: Tue, 4 Mar 97 09:16:38 -0800 From: Randy Grein To: Subject: Re: Speed >I have a small netware 4.11 network with about 50 users. (Token-ring, 3 >netware servers, 1 NT, AS/400 etc.) The company have about 250 workers >and most are still on twinax. We are moving in about 5 months and I'm >networking everyone. I think there's a few things you need to understand to really appreciate the issue here: The control issues between token ring and ethernet pretty much disappear in a switched environment. Collision issues are handled by the switch, so the control mechanisms in the protocols aren't really used except at the endpoints, where you MIGHT want to have shared media - MAUs or hubs. There's an important distinction between speed, throughput, network, efficiency and responsiveness. Sure, token ring is 60% faster than standard ethernet - does a better job dealing with congestion, too. But there's no full duplex, fast, or full duplex/fast options for token ring, making it's raw speed options much, much slower. There's a philosophy distinction, also. Many token ring shops try to squeeze every last drop of bandwidth out of a ring. There's a good reason, too - historically token ring has been 3-5 times the cost of ethernet, so of course you'd want to optimize that resource. However, 90% average utilization on a token ring segment tends to mean a sluggish network - users will not receive much of the available bandwidth, requiring you to minimize the amount users require. So you might stuff 70-100 users on a ring to achieve that high efficiency, but each user would receive 16,000,000 megabits/sec divided by 100 users, or 160 k/s average bandwidth. Let's put those same 100 users on a 10/100 switch; let's say a full duplex fast ethernet port to the server and 10 users each on 10 ports. Last time I checked people were getting about 70 megabits/s throughput to a server on such configurations, so we're i/o bound at the server - not so bad; each users has an average bandwidth of 70,000,000 bits/sec divided by 100, or 700 k/s. With a faster server/more servers to move the bottleneck, those 10 users would then get a full 100 megabits/100, or 1 megabit - give them each a dedicated switched port, and the numbers get better - 20 megabits each. It IS possible to do the same with a token ring switch, but the cost is out of sight; whereas it's merely expensive to give each user a switched ethernet port. Of course, there;s also the issue of the fast port to the server - there is no fast token ring available, which severly limits your options. You COULD go with 100 VG, but I don't know if there's any switches available to do 100VG-token ring conversion. There's one other emerging technology that will be important in this, also - gigabit ethernet. It's already available as proprietary hardware, and should be ready for prime time within a year to 18 months. Quite an upgrade path. For those who are yelling ATM, I'd say that it's time has come and gone. It was never a LAN protocol, really - all kinds of shoehorning were needed to get LAN traffic working on it, it's expensive, and last I heard the standards committee had ajourned with no way to deal with congestion problems and no more meetings planned. So, in summary I'd strongly urge you to migrate to a switched ethernet - there ARE ethernet cards for the AS400, and you can mix/match the pipe sizes to match the throughput needed. --------- Date: Tue, 4 Mar 1997 11:33:14 -0600 From: "Kevin McIntosh" To: Subject: Re: Speed I'll take [switched Ethernet] every time. Wire it to the 256b spec. for UTP cabling, so it's easier upgrading to from 10BASE-T to 100BASE-T. I also recommend a hardware solution to get to the AS/400. By the way, they are working on a 1GB standard for use with CAT5 UTP. --------- Date: Tue, 4 Mar 1997 11:34:04 -0600 From: "Mike Avery" To: netw4-l@ecnet.net Subject: Re: Speed >I have a small netware 4.11 network with about 50 users. >(Token-ring, 3 netware servers, 1 NT, AS/400 etc.) The company have >about 250 workers and most are still on twinax. We are moving in >about 5 months and I'm networking everyone. Some people innocently assume that this was a technical question. Based on the sorts of response that this sort of question usually gets, it's a religous issue. There are the Ethernet junkies and the Token Ring bigots, and both are ready to tell you that your network will go down in flames if you use the other topology. You windup with people talking about how ethernet can only do 4mbps, when benchmarks show that in small networks close to 100% of the bandwidth is available, or that token ring can't handle IP, or other dreck. In any case, with 100mbps ethernet in the mix, the old rules of thumb no longer apply. In any case, a 50 user LAN is not rocket science, almost anything should be adequate, depending on what they are doing. (Some of my comments may reflect my experience in larger environments - I've worked in shops from 1,200 to 20,000 nodes.) Since you are moving to a new facility, the most important consideration is to not paint yourself into a corner. Make sure that as much of your cable plant investment as possibe is reuseable. This means I suggest cat 5 cable everywhere. And make sure you run enough of it, using centralized cable rooms - perhaps one or two per floor. The cable rooms should handle phones, networks, faxes, anything that can go thorugh the cables. Run at least 3 sets per person per office, with more in conference rooms. The cheapest time to run cable is before you move in. So plan ahead. It will make moving people much cheaper, and if you discover that some needs a computer, a phone, and a fax, you'll be able to accomodate them without having to run more cable - just move jumpers in the wiring closet. As to what to run on the cat 5 cable, that's another question. You will probably face some questions from your management about cost justifying any changes you propose. And it is difficult to cost justify a topology switch, unless there are serious issues that suggest that the time is right. Moving from one building to another and switching to cat 5 UTP may make some of your existing hardware unuseable in the new environment, which is a reason to consider changing topologies. Or, "Since we have to replace a lot of gear anyway, is this a good time to switch topologies? What will be cheaper today and tomorrow?" I have worked in token ring and in ethernet shops. Plain ethernet, not 100 base whatever. And I have no problem working with either. So I'll let sum up the differences that matter (to me). In a well setup and well maintained shop, there's not that much difference. When you start pushing the envelope, token ring has some advantages. But, honestly, it's cheaper to do it right with ethernet than to do it poorly with token ring. As traffic grows, ethernet will bog down sooner and harder than token ring. The best description of the differences I have heard was from a woman who moved from an ethernet based LAN to a new employer who used token ring. And this was 4mbps Token Ring and 10 mbps Ethernet. Her comment was, "Token ring is never as fast as Ethernet - or as slow." Personally, I would have trouble justifying a new token ring installation. I would look at 100mbps ethernet for backbones between servers. For any platforms that don't offer or support 100mbps ethernet (SCO Unix, last time I looked was in this position), I'd put it on a 10mbps ethernet switch so those nodes could get a solid 10mbps. (Side note - my last shop used FDDI. They were concerned that the FDDI was getting saturated, so we hired a guy with a FDDI Sniffer to check out load levels. We had a 10 minute peak once a day where we reached 6% utilization. All in all, I don't feel FDDI is worth the extra cost in most installations.) At this time you can get decent 10/100 mbps ethernet cards quite reasonably, so I'd select a brand and model I liked and stick with it to make sure that I could support either speed at the nodes with no further hardware investment - including user down time while someone plays with their computers. I'd look at DEC, 3COM, and Intel. At this point, if you install 10 mbps cards, chances are you'll just have to swap 'em out later, paying for them twice. The next big question is, do we want to distribute 100mbps to all the desktops? While the NIC's are cheap, the hubs are still kinda pricey. And since hubs are centralized, they are fairly easy to switch out as pricing improves. It might be a good idea to put a 100/10 mbps switch in place and use that to connect to 10mbps hubs to support users. If users develop a need for more speed, they could be moved to 100mbps hubs as needed, where needed, and as the budget allows. I'd certainly put 100mbps in place around the campus, between the main computer rooms and the wiring closets. Again, it is pretty easy to swap out router modules and hubs (or hub modules if you use large hubs - but do a careful cost analysis here, it may be cheaper to buy stackable hubs and throw them away than to purchase and upgrade large hubs). The suggestions above let you meet todays needs and prepare you for the future. ------------------------------