Date: Wed, 25 Feb 1998 00:12:33 -0600 (CST) From: Chris Dillon <cdillon@wolves.k12.mo.us> To: Greg Lehey <grog@lemis.com> Cc: Adam Turoff <AdamT@smginc.com>, hackers <hackers@FreeBSD.ORG>, Robert Glover <rob@f-body.org> Subject: Re: Token Ring for FreeBSD yet? Message-ID: <Pine.BSF.3.96.980224224016.306A-100000@duey.hs.wolves.k12.mo.us> In-Reply-To: <19980225122411.62329@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 25 Feb 1998, Greg Lehey wrote: > > I wouldn't exactly call Token Ring slow just because it is only running at > > 4 or 16Mbit. > > Correct. There are other reasons to call it slow. > > > The 16Mbit Token Ring network could run circles around any 10Mbit > > Ethernet network. > > I disagree strongly with this statement. > > > On a heavily congested network, even a 4Mbit Token Ring network > > could outrun a 10Mbit Ethernet network, simply because of the > > token-passing scheme that Token Ring uses. > > On a normal network, a 10Mbit Ethernet network could outrun a 16Mbit > Token Ring network, simply because of the token-passing scheme that > Token Ring uses. While I haven't actually done calculations on what the overhead would be for passing the token around compared to just spitting a packet out on an Ethernet, there ARE several more advantages I can think of besides a lack of contention for the media. For example, can you guarantee, mathematically, that you can get a given mount of data across the network in a given amount of time, worst-case? Can't do that with Ethernet, since it works too chaotically. In token-passing and polling based networks, you can say with certainty that even under maximum load, you can get a packet from one machine to another in X milliseconds. It offers a QoS you just can't get with Ethernet. I'm not arguing that Token Ring isn't dead... I'm just saying it isn't as bad as some people think and has its merits. :-) > > CSMA/CD just isn't very efficient on a heavily loaded network. The > > CSMA/CD network (Ethernet) would spend more time dealing with > > collisions than it would passing usable data. > > Correct. But token passing isn't very efficient under any kind of > load. I suppose that depends on the particular scheme that has been implemented. "Early token release", which I believe is implemented in FDDI, can reduce that inefficiency greatly. > > FDDI and Arcnet have the same advantages. > > So why are they both so popular? Why is Windows so popular? :-) I think we all know that just because a technology is in wide-spread use doesn't mean there isn't anything better out there. Ethernet became popular most likely because it was just cheaper, never mind the technical merits of all the other networking technologies out there. > > There was even an 80Mbit Arcnet proposal at one time, which would > > have been much better than Ethernet. Frankly, I would consider > > Ethernet just above SneakerNet in the protocol arena, not the other > > way around. :-) > > I did some theoretical calculations a while back to show the amount of > overhead in CSMA/CD and in token passing. I've forgotten the details, > and I can't find the calculations, but the token-passing overhead was > much larger than you'd expect. It's rather like the difference > between catching a train and taking a car. Ignoring the speed > difference between cars and trains, the big problems are: > > - Cars can become very slow in traffic jams. Trains are not usually > susceptible to traffic jams. > - You have to wait for trains. VERY good analogy. :-) The only reason I brought this up at all is because an old professor of mine sparked a light about just WHY some of these seemingly slower (judging by bit-rate) networks can actually be faster than their higher-bitrate cousins under certain circumstances. Same reason you shouldn't judge how fast a processor is just by its clock rate. I was merely hoping to belay some of the common misconceptions. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980224224016.306A-100000>