Skip site navigation (1)Skip section navigation (2)
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>