Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!hp9000.csc.cuhk.hk!saimiri.primate.wisc.edu!sdd.hp.com!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!uunet!yeshua.marcam.com!charnel!psgrain!percy!davidg From: davidg@percy.rain.com (David Greenman) Subject: Re: ed0: warning - reciever ring buffer overflow Organization: Percy's BSDI, Portland, OR, USA Date: Mon, 20 Sep 1993 22:10:30 GMT Message-ID: <CDoAxI.2y6@percy.rain.com> Lines: 65 >>I probably wasn't very clear in my original post. In a span of 10 >>minutes I've gotten over 100 of these warnings. They almost always >>happen when I'm heavily using NFS, and they even seem to cause >> >> nfs server <host>:<mnt-point>: not responding >> nfs server <host>:<mnt-point>: is alive again >> > >Wow, just 100 :-) I think the last counts I made got to over 5000 of these >messages over a few days. >Anyway I ignore them and everything seems to keep on working. >I strongly suspect that they have a lot to do with NFS. ... >SOmething sure is wrong if so many packets are being junked but performace >still seems real good, NFS performance is the best I have ever seen. > >My next step is to get another SMC Elite 8 bit card and see if this makes >any difference - maybe my WD8003 is too ancient to cope with that >excellent ed0 driver. >If that fails then its time to edit out the warning message. >Can anyone suggest what the problem/cure might be? It always surpises me that people don't just ask the original author these questions. :-) Anyway, the reason these are happening is that the access to the 8bit boards shared memory simply isn't fast enough to deal with full wire speeds...but the driver tries hard...so even though packets get dropped, your performance only drops to about what the ethernet board is capable of (should be in the 400-600k range with an 8bit card). NFS is especially bad because the UDP window is quite large (40k last time I looked), so the overflow condition can happen easily. I've explained this for the most part in the release notes for the driver, but these didn't make it into either the FreeBSD or NetBSD releases (we couldn't find an appropriate place to put them). From the release notes: receive ------- The 8390 implements a shared memory ring-buffer to store incoming packets. The 8bit boards (3c503, and 8003) usually have only 8k bytes of shared memory. This is only enough room for about 4 full size (1500 byte) packets. This can sometimes be a problem, especially on the original WD8003E and 3c503. This is because these boards' shared memory access speed is also quite slow compared to newer boards - typically only about 1MB/second. The additional overhead of this slow memory access, and the fact that there is only room for 4 full-sized packets means that the ring-buffer will occassionally overflow. When this happens, the board must be reset to avoid a lockup problem in early revision 8390's. Resetting the board will cause all of the data in the ring-buffer to be lost - requiring it to be re-transmitted/received...slowing things even further. Because of these problems, maximum throughput on boards of this type is only about 400-600k per second. The 16bit boards (8013 series), however, have 16k of memory as well as much faster memory access speed. Typical memory access speed on these boards is about 4MB/second. These boards generally have no problems keeping up with full ethernet speed. The only problem I've seen with these boards is related to the (slow) performance of 386BSD's malloc code when additional mbufs must be added to the pool. This can sometimes increase the total time to remove a packet enough for a ring-buffer overflow to occur. Hope the above helps... -DG David Greenman davidg@implode.rain.com