RING vs. ETHER - Theory and practice.


Ron Natalie (ron@BRL.ARPA)
Sat, 19 Jul 86 12:15:45 EDT


      Dave Clark once again observes that a token ringnet outperforms an
      Ethernet in handling back-to-back packets. The ringnet has an
      automatic retransmission function built into the network
      interface, and will retransmit rejected packets until they get
      accepted, while an Ethernet interface loses subsequent packets if
      they follow the first one too closely.

In theory, but let us look at two fielded devices. The INTERLAN N1010A
Ethernet interface and the PROTEON 10MB RINGNET. The INTERLAN handles
multiple incoming packets by buffering some number of messages comming
in from the net in interface memory while waiting for the host to begin
the data transfer. The PROTEON can not accept back to back messages
because the board does not reset to copying messages from the interface
after the end of the first message so it misses the header of the second
message. There is no automatic retransmit because the source board drains
the ring until it sees its own message come back, which should be at the
beginning of the train of messages. It can't leave it in the ring, because
it will be eaten by another interface who had transmitted a message. It
can't retransmit until the token comes by. I've tried reenabling copy
as soon as the DMA has finished, but there is still a delay, and I also
feel that something is amis in the interrupt logic when I do this.

You are still at a slight win because it is possible for the lower levels
to tell when retransmission is needed, however, a lot of retransmission
is needed because of the misdesign of the interface, significantly more
so than is ever needed on our Ethernets.

Not to say that I am down on the Proteons, much of what we are doing at
BRL would be difficult or impossible without them. I just wish they
could double buffer so that you would not miss the header of successive
packets.

-Ron



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:34 GMT