[rescue] FDDI card

[Greg A. Woods]

[ On Sunday, February 24, 2002 at 13:50:54 (-0600), Scott Newell wrote: ]
> Subject: Re: [rescue] FDDI card
>
> At this point, it's starting to sound to me like some very reasonable
> engineering decisions and tradeoffs could evolve into something like where
> we are today with 10Base-T.

Exactly my point!  ;-)

>  I'm not trying to be facetious or
> pedantic--this subject is interesting to me.  (Especially if we can get to
> something clever that will work over rs-485...)

Yes, you're exactly right.

Although the original Ethernet(tm) design could have used N channels, be
they on separate carriers on the same wire, or separate wires, or
whatever, eventually you still have to deal with channel allocation
issues in a many-to-many network (at least when the number of stations
is higher than the number of channels).  So far as I know there are only
two possible solutions -- token passing of some sort (and even ATM fits
in this category); and collision-sense multiple-access (hopefully with
some kind of collision detection for the inevitable collisions). :-)

Of course you could just run star networks with centralised N-way
store-and-forward switching, and then every station gets to do full
duplex communications with the switch and then all this CSMA/CD stuff
can go out the window again...  :-)

If you really have to avoid the star network topology for whatever
reason then token passing is the engineer's ideal solution in terms of
predicting scalability and performance, but CSMA/CD has some key
practical advantages.  I suspect if switching bridges had never got so
fast and so cheap then maybe ATM or FDDI would have gone to the desktop,
but since the latter (well at least ATM) require hardware technologies
very similar to what's needed for high speed store-and-forward
switching, Ethernet won out because it was the installed base and thus
conceptually easier to upgrade, even if not cheaper in the long run.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods at acm.org>;  <g.a.woods at ieee.org>;  <woods at robohack.ca>
Planix, Inc. <woods at planix.com>; VE3TCP; Secrets of the Weird <woods at weird.com>