🚀 go-pugleaf

In article <1992Nov19.193651.21854@umr.edu>, rfranken@mcs213f.cs.umr.edu (Richard Brett Frankenberger) writes:
Newsgroups: comp.dcom.lans.misc
From: rfranken@mcs213f.cs.umr.edu (Richard Brett Frankenberger)
Subject: Re: Token Ring vs. Ethernet
Date: Thu, 19 Nov 1992 19:36:51 GMT

>In article <sige6ao@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>>-Ethernet is still cheaper, and that is not likely ever to change.
> 
>True.
>
>>-Ethernet is simpler and so more robust.  Any single ring scheme is a
>> royal pain compared to ethernet.  The hassles of source routing and
>> other token ring "features" must be experienced to be believed.
>
>It's more robust?  Really?  What happens if a faulty transciever cable in
>ethernet is messing up the entire line?  Nothing.  On Token-Ring?  The
>workstation will remove itself from the ring.  I can bring down an ethernet a
>lat easier than I can bring down a token-ring.  And I can get a token-ring back
>up faster than an Ethernet.

	And I can take a token ring down pretty quick too.  (see below)

>>Simpler?  No disagreement there, but that doesn't mean its better.  (It is
>>one of the reasons Ethernet is cheaper, but other than that, I don't see
>>any benefits from its simplicity).

	One of the benefits of simplicity is that is more likely that
people get the configuration right and can prove it.   Or if they get
it wrong, they can figure it out quicker.


>The hassels of source-routing? No big deal ... I manage a WANof about 30      
>TR's allsource-routed togethor (now being converted to routers).  Source
>routing is no major problem (certainly less confusing that setting up
>IP routing).  BUT, if you don't like it, you don't have to use it.
>Anyway, source-routing is more like bridging than routnig (in several
>ways), and in a large WAN, you are better off with routers anyway.

	Source Routing _is_ bridging, just unlike Spanning Tree Transparent 
Bridging, you _have_to_ manually configure it AND it's not transparent.
Many Ethernet customers plug in their bridges and forget them.
 
>On ether net, you can get between segments one of two ways.  Transparent
>bridges or Routers.  On token-ring, you have those two options PLUS  
>Source-Routing.  Source-Routing is just another option.  You don't have
>to use it.  (Yes, IBM's SNA over LANs is based on source-routing, but
>that doesn't work over Ethernet normally anyway (yes, it can be done); but
>you could use the same tricks to run it over Ethernet to run it over
>token-ring without source-routing).
 
	In the past it's been fairly difficult to get transparent Token
Ring bridges.  Hopefully deployment of SRT will start the decline of
Source Routing.  well at least it will standardize it.  Quick tell me which
standard SR has been described in prior to SRT?

>-10MHz Ethernet is faster than 4Mb/s token ring.  A pair of 16Mb/s token
> ring stations can be 60% faster than a pair of ethernet stations,
> but mostly because of the underlying bandwidth.  At the (now) low
> speeds of ethernet and token ring, there is no interesting effeciency
> difference for stations (not hubs or switches) between packet sizes
> of 1500 and 16K.

>Really?  On a 4 MBPs token-ring, I ran some large file copies at approx 1.5K and
>4K packet sizes.  The 4K was about 25-50% faster (I can't remember exactly).
>Of course, for smaller transactions, the difference is less, but still
>noticable.  (This test was done with a lightly loaded Novell file server with
>Packet Bursting (without packet bursting, the difference would be even more
>pronounced).

	I have never seen a reasonable protocol running faster on a ring
than Ethernet.  Veron is correct, just do the math.  Token Ring's birthing
problem has been (and still is) miserably slow adapter chip implementations.

	I can saturate a 4Mbs Token Ring with 3 to 4 PCs running DECnet.
It takes a few more for me to do that on an Ethernet.  No matter what the
packet size, 10Mbps Ethernet still have more throughput than 4Mbps TR, and
less than 16Mbps.
 
>... 
>Ethernet is far more common and not significantly worse than token
>ring.  Since token ring is not significantly better (it can be argued
>to be worse since it is so much more fragile), token ring is dead in
>the long run.  The universe does not tolerate competing, largely
>equivalent standards forever; eventually the less common one disappears.

	Probably the most valid thing you've said.  The only way that
token ring will survive is if it becomes more cost competive.
 
>Token-ring won't die.  Eventually, FDDI will be much more common than E-net and
>TR.  FDDI is token-ring over fiber-optic, basically.  Then token-ring concept
>is superior to the CSMA/CD concept used by Ethernet.  It is more robust,
>have lots of error checking and correction built in, and  it is designed to
>take heavy loads into account and share the bandwidth as fairly as
>possible (Ethernet's method is just let them collide and we'll randomly pick
>who gets to send).

	But you vasilate, the so called superiority of token ring doesn't seem
be borne out in practice.  Token Ring has it's own bogy man, _jitter_.
I've seen rather small networks become totally unusable due to jitter.
Was Beta better than VHS?   Does it matter?

>Bottom line,  You probably won't go wrong with either, but with token-ring, you
>won't have to worry about one user sticking a pin through the cable and downing
>the entire net.  (Not that that's a likely occurance, but it makes the point
>about token-ring's robustness).  Ethernet will likely be cheaper, however.

	This is totally and utterly specious.  Unfortunately I hear the same
type of comments from the big token ring company too.

	Token Ring is just a vunerable as Ethernet to LAN outages when the 
main trunk cable is mangled in some way, either accidentally or on purpose.
802.5 does not have a way to autowrap broken trunk segments.  The 8228
relies on the IBM STP MIC loopback, which does nothing for sticking a pin
in a Type 1 wire either.  

	In fact it is trivial to break a token ring totally in many ways:
- cut the trunk(as above),
- put an adapter cable (no loop on end) in a RI/RO port
- crosswire RI/RO ports (took me a while once on this one), 
- stick a lobe cable in a PC monocrome jack (never tried it myself)
	(rumor has it that it satisfies phantom current requirements)
- always a favorite: insert a station of the wrong speed
	(station alternately causes the ring to beacon and drop out
	but keeps re-inserting because it's local lobe test works)
- a stuck lobe relay  (I've never figured out how this happens, but
	some people swear that the relay reset gadget that comes with
	the 8228 has fixed their rings many a time)

	A better measure of a LAN technology's "goodness" is how easy
it is to avoid problems.  While 802.5 seems easy at the drop level, at the
ring trunk level there are many things that still can go wrong.  
	Have you ever tried to figure out exactly how
much cable you can use and how long the lobe loops can be?  It takes charts
and charts.  Try to correlate those charts between vendors.  Try to figure
them out from first principals?

	Ethernet configuration rules can almost be put on one sheet of
paper.  The 802.5 standard doesn't even agree with the numbers in the IBM
specs.  Guess which one is "right".  what does "right" mean?

	"Token Rings happen"

	Dave Mitton
	Token Ring Program
	Networks and Communications 
	Digital Equipment Corp.