Path: utzoo!utgpu!attcan!uunet!husc6!cmcl2!rutgers!apple!bionet!agate!ucbvax!RICE.EDU!retrac
From: retrac@RICE.EDU (John Carter)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: 4BSD TCP Ethernet Throughput
Message-ID: <586.retrac.titan@Rice>
Date: 7 Nov 88 04:08:08 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 38


    This is a short followup to a posting I made a while back in which
I responded to Van Jacobson's comments on the poor performance of the
Intel ethernet interface in the SUN-3/280 and similar workstations.
At the time I commented, I had not fully completed my re-implementation
of the V bulk data IPC protocols for the Intel interface.  I recently
completed a a version, and want to make a few corrections to my previous
posting.

    I seem to have been a little hard on the Intel interface.  I am able
to get *peak* process-to-process throughputs (measured as I laid out in the
previous posting) of a little over 8 Mbps (up to 8.2).  This corresponds
to a 1 Mbyte transfer taking about a second (8.4 million bits in 1.02 secs
is about 8.2 Mbps).  Unfortunately, it isn't very stable - it seems to
fluctuate between 6.5 mbps and 8.2 mbps.  It appears that packets are
getting dropped quite often, causing timeouts (argh).  I'm not sure if
it's the interface or a flaky network (outwork net isn't a prime example
of a well laid out and administered Ethernet...).

    Oh yeah, the above numbers are SUN-3/50 -> SUN-3/180.  The best that
I can get the Intel interface to transmit at is 6.3-6.5 mbps.  I attain that
by chaining together 32 packet descriptors for transmission at a time,
then waiting until I get an ACK before I chain the next 32 (no shadow
descriptors, i.e. setting them up while awaiting the ACK).

    This dichotomy (transmit vs receive) seems quite strange, and I don't
have an explanation for it.

    The Intel implementation is quite a bit smaller, thanks to it not
having as many annoying "features" as the LANCE, particularly not having
a hardware CRC tailer appended on every packet (which really made the
optimistic blast implementation gross for handling certain error cases).

John Carter
Rice University

P.S. Several people asked for my opinions on interfaces and such not.
     I've been quite busy lately, I'll try to repond soon.