Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!MONK.PROTEON.COM!jas
From: jas@MONK.PROTEON.COM (John A. Shriver)
Newsgroups: comp.protocols.tcp-ip
Subject: maximum Ethernet throughput
Message-ID: <8803111925.AA21604@monk.proteon.com>
Date: 11 Mar 88 19:25:29 GMT
References: <8803110041.AA16286@monk.proteon.com>
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 35

One way to deal with those violent controller speed mismatches that
are starting to show up is to use a LAN with some form of hardware
ACK.  This is part of all token ring networks (ProNET, Apollo, 802.5,
FDDI), as well as Hyperchannel and DEC's CI.  While these bits cannot
be used to guaruntee end-to-end reliability, they do let you know when
you are sending faster than the other guy can receive.

The simplest thing to do is just retransmit until the other guy copies
it, but this is a waste of network bandwith.  The more sophisticated
thing to do is put the packet back on the front of the output queue,
and search up the queue for a packet to a different hardware
destination.  This way the packet retransmissions are interleaved with
potentially useful transmissions.  You don't, however, want to shuufle
the order of packets to a particular node, this can be pathological to
some protocols.  (The NSP in DECnet-VAX did not accept out-of-order
packets until Version 4.7, some TCP's have the same problem.)

Good programming interfaces are indeed important.  While our earlier
boards were only single-buffered (one each way), their simple and fast
programming interface (start a transmit in 4 C statements) made up for
it.  (The ACK bit also helps on the single-buffer problem.)

It is very hard to try and get below the interrupt-per-packet
threshold and keep a simple programming interface.  However, even if
you make it, you run into programming interfaces, such as the 4.3bsd
network device interface, that make it very difficult to get a
pipeline going.  By comparison, in VAX/VMS, where pipelining is quite
feasible, when you pipeline two packets deep, you nearly double the
throughput.

As an example of how programming interfaces and interface design
affect performance, note that Van's benchmarks were run on a Sun-3/50,
which uses the AMD LANCE Ethernet chipset.  I doubt he could match
those numbers on a Sun-3/160, which uses a Intel 82586 Ethernet chip.
The '586 has an inferior programming interface, and some nasty
internal "housekeeping" delays that make it a good bit slower.