> > That should work, but you've got to be really careful about ground loops
and
> > think about noise.
>
> Why noise?  The signal is digitally reconstructed at each node...
> Forwarding is done packet by packet (or after N bytes of delay to check
for
> the address.)  (except when a node is off and the signal travels through
> NC relay contacts or something...)

I didn't see the original message, but I was assuming a bunch of nodes would
be connected that could be some distance apart.  Noise can get into long
signal runs in various ways.

> Well, yes, but I'm not sure why THAT was considered necessary?  ie - is it
> only required to acheive the predictability that TR afficiandos used to
> claim was so important?  Theoretically in an ABCD ring, A can send to B
and
> C can send to D simultaneously without interfering with each other at all.
> Further, if you have a "master node", then can its messages be a sort of
> "implicit token"?

Assume a ring of 26 nodes with A sending to B, B sending to C, ..., Z
sending to A.  In theory, A could send to B independently of C sending to D.
However, this gets very cumbersome to manage.  What if C decided to send to
D, but B was trying to send to E?  How is B supposed to know that it can't
right now?

Another thing to consider is that each node forwards bits, not messages.
Therefore a signal from A shows up at Z after 25 logic delays and cable
propagation delays.

The token in a token ring is really just the permission to send.  You give
up the potential efficiency of having multiple messages being transmitted at
one time when all the conditions are right.  In return you get good use of
the bandwidth at saturation with relatively simple management.  When a node
receives the token, it passes it on immediately if it has nothing to send.
If it has something to send, it sends one packet and then passes on the
token.  Nearly 100% of the ring bandwidth is used as long as any node has
something to send, without degredation when lots of nodes want to send.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olin@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu