Subject: Re: Q840 ethernet performance?
To: Dave Huang <khym@bga.com>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: port-mac68k
Date: 11/03/1997 09:54:01
On Sun, 2 Nov 1997 23:39:14 -0600 (CST) 
 Dave Huang <khym@bga.com> wrote:

 > > I get these messages...
 > > 
 > > ae0, warning - receiver ring buffer overrun.  The other UNIX host reports a
 > > 65% packet loss. Roughly the same numbers hold true if I use "ping -f
 > > <840av>" to flood it. 
 > 
 > I don't know about that one... I get the same message if I spray my 386
 > with NE2000 clone ethernet card, which I'm pretty sure uses the same chip
 > and driver as your Asante (National Semiconductor 8390). My 386 can handle
 > a flood ping without dropping any packets though.

Yah, the reason for that is that there is typically not very much memory
on dp8390-based cards.  I've just been doing some work on the dp8390
driver (and the front-ends for the 3Com 5c503 and the WD8003 family and
SMC Elite Ultra) ... the 3Coms typically have 8k of memory which
is split up into 1 transmit buffer and the rest for receive buffers.
NE2000s have 16k given to 2 transmit buffers and the rest for receive.
Some SMC Elite Ultras have 64k.  The more given to receive buffers,
the less chance you'll get a receive ring overrun.

 > The MACE driver DMAs in and out of the MACE chip, so that might make the
 > performance better too... I'm still working on the driver, and hopefully
 > I'll be able to make the performance even better... round trip time on
 > pings isn't too good right now, average seems to be over 10ms for 64 bytes
 > packets. I think I know why that's happening though. :)

Ping round trip times are often affected by interrupt latency (ping a
system running Windows NT sometime :-).  Macs are notorious for having
braindamaged interrupt layouts... this could be biting you.

Someone might want to take a look at the interrupt code I wrote for
the hp300 port.  It dynamically computes the levels assigned to
spltty(), splnet(), splbio(), etc. as interrupt handlers are established.
It could help deal with this interrupt latency problem my making the
adjustments on a per-machine basis, rather than catch'alling the levels
(which is also what the old hp300 code used to do).

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-6                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 415 428 6939