*BSD News Article 62587


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!newshost.telstra.net!act.news.telstra.net!psgrain!news.uoregon.edu!news.rediris.es!ordago.gsyc.inf.uc3m.es!usenet
From: carlos <calb@ordago.gsyc.inf.uc3m.es>
Newsgroups: comp.unix.bsd.netbsd.misc
Subject: Re: ring buffer overflow with 386PC and 16 bit SMC ethernet card..
Date: Sat, 02 Mar 1996 10:38:17 +0100
Organization: GSyC, Universidad Carlos III, Madrid, Spain.
Lines: 86
Message-ID: <31381709.41C67EA6@ordago.gsyc.inf.uc3m.es>
References: <4gl05b$no@news.iastate.edu>
NNTP-Posting-Host: fantasma.gsyc.inf.uc3m.es
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.0 (X11; I; BSD/386 uname failed)

hello


------------------------------------------------------------------------

6.4.5   I get a lot of 'ring buffer overflow' messages using NFS and the
        ed0 driver.  Is there a problem?

        David Greenman (davidg@implode.rain.com), the original author of
        the ed0 driver, provides us with some insight into the inner
        workings of the ed0 driver.

           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.

        With NFS, the problem is really bad, though.  The 3c503 does not
        have enough memory on the card to support the default 8k packets
        that NFS and other protocols use as their default.  The solution
        for folks that are having a problem with ring buffer overflows
        in NFS is for them to either use the -r and -w flags to limit
        the packet size or use the define "NFS_BOOT_RWSIZE=8192".  If
        NFS doesn't work with this defined, the code will automatically
        step down to the next smaller increment.  If you KNOW that you
        will always be running a 3c503, you can set this define to 4096
        instead, just to make sure.  This should eliminate the bulk of
        the ring buffer overflows in NFS.
----------------------------------------------------------------------
						calb.
____________________________________________________
     ___   _____  _   ____    
    / __// _   // /  / o)    calb
   / /_ / /_/ // /_ /  \ ordago.gsyc.inf.uc3m.es   
  /___//_/ /_//___//__)
____________________________________________________