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