Subject: Re: le0: overflow
To: None <port-sparc@netbsd.org>
From: Robert Elz <kre@munnari.OZ.AU>
List: port-sparc
Date: 12/18/1998 09:48:10
    Date:        Thu, 17 Dec 1998 14:47:40 -0700 (MST)
    From:        Tim Rightnour <root@garbled.net>
    Message-ID:  <XFMail.981217144740.root@garbled.net>

  | On 17-Dec-98 Greg A. Woods spoke unto us all:
  | #  but if that data is coming over TCP connections, then TCP flow control
  | #  should slow things down to a rate that even a VAX could handle.
  | That would explain his lossage with NFS,

No, it wouldn't.   Please let me say this once again.   A lance "overflow"
error occurs entirely within one packet.   It makes not the slightest bit of
difference how many other packets are being sent or received or when.  A
single packet, with none for hours before, or after, it could trigger
exactly the same event.

What does make a difference is how much contention there is on the memory
bus - which cannot be other packets (the lance can only receive or transmit
a single packet at a time), but could be (but apparently isn't in this
particular case) other devices competing for DMA cycles, or it could just
be the CPU competing for memory - doing a lot of X screen updates (drawing
into video memory) could do it, as could just regular program accesses to
ram, if they're missing the cache.

kre