Subject: Re: hardware compatibility
To: Nathaniel D. Daw <ndd2@columbia.edu>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-i386
Date: 07/16/1996 12:50:49
Michael VanLoon writes:

>The 3c595 is supposed to work in current.  I don't know how stable or
>high performance it is.  Mika?

ttcp shows 25 Mbits/second TCP throughput between linux 2.0.x boxes,
23Mbits/sec from NetBSD->Linux, and 36Mbits/second for
NetBSD 1.2A  -> Linux 2.0.7.

Strange, considering that the Linux loopback ttcp throughput is
approximately 7 percent better than NetBSD:  93Mbits/sec versus 87.

All numbers are on Intel-motherboard 120MHz P5s, 32Mbytes EDO ram:
AFAIK, identical hardware to Mika's.  The TCP numbers are from
otherwise-idle hosts connected via a 100Mbit switched-ethernet board
in a Cisco catalyst. I don't know how the switching affects throughput
or latency versus a nonswitched hub.


I'd hazard a guess that, with a sustained packet stream,  the SMC's
ringbuffers are amortizing interrupts across multiple packets, whereas
the 3com cards seem to require an interrupt per packet, and currently
require a software copy from the FIFO to an mbuf.  The 3com driver could
be redone to DMA into (or out of?) a single mbuf, but still needs
an interrupt per packet. From the 3com docs it's not clear  its' a win.

Guessing, wildly, from 3Com's published performance numbers,  a polling
driver may in fact be a good compromise.

Has anyone else experimented with folded copy/checksum? That is
reported to be the source of the (large) gains in the Linux TCP
performance.