
----------------------------------------------------------------------
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" <mavery@aus.sig.net>
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.  <g>

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.  <g>

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" <mavery@aus.sig.net>
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" <mavery@aus.sig.net>
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? <grin?> 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? <grin!>

------------------------------

Date: Thu, 11 Jan 1996 07:39:10 -6
From: "Mike Avery" <mavery@aus.sig.net>
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" <mavery@aus.sig.net>
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" <mavery@aus.sig.net>
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

<snip>
>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.

<snip>

>>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 <JRD@CC.USU.EDU>
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 <JRD@CC.USU.EDU>
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 <JRD@CC.USU.EDU>
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 <JRD@CC.USU.EDU>
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 <JRD@CC.USU.EDU>
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 <skurz@NORFOLK.INFI.NET>
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 <JRD@CC.USU.EDU>
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 <JRD@CC.USU.EDU>
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" <herronr@smeco.com>
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 <rgrein@halcyon.com>
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.
<snip>

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" <powertek@hia.net>
To: <netw4-l@ecnet.net>
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" <mavery@mail.otherwhen.com>
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.
<snip>

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.

------------------------------

