Date: Mon, 22 Nov 2004 16:14:15 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Sean McNeil <sean@mcneil.com> Cc: freebsd-current@freebsd.org Subject: Re: Re[4]: serious networking (em) performance (ggate and NFS) problem Message-ID: <200411230014.iAN0EFZn058709@apollo.backplane.com> References: <20041121205158.45CE.SHINO@fornext.org> <200411220038.iAM0c7JQ052589@apollo.backplane.com> <20041122104527.5204.SHINO@fornext.org> <1101100870.16086.16.camel@server.mcneil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:Increasing the interrupt moderation frequency worked on the re driver,
:but it only made it marginally better. Even without moderation,
:however, I could lose packets without m_defrag. I suspect that there is
:something in the higher level layers that is causing the packet loss. I
:have no explanation why m_defrag makes such a big difference for me, but
:it does. I also have no idea why a 20Mbps UDP stream can lose data over
:gigE phy and not lose anything over 100BT... without the above mentioned
:changes that is.
It kinda sounds like the receiver's UDP buffer is not large enough to
handle the burst traffic. 100BT is a much slower transport and the
receiver (userland process) was likely able drain its buffer before
new packets arrived.
Use netstat -s to observe the drop statistics for udp on both the
sender and receiver sides. You may also be able to get some useful
information looking at the ip stats on both sides too.
Try bumping up net.inet.udp.recvspace and see if that helps.
In anycase, you should be able to figure out where the drops are occuring
by observing netstat -s output.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200411230014.iAN0EFZn058709>