Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Jul 2009 16:40:03 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Chris Hedley <freebsd-current@chrishedley.com>
Cc:        freebsd-current@freebsd.org
Subject:   Re: Linux NFS ate my bge
Message-ID:  <200907222340.n6MNe3K5013221@apollo.backplane.com>
References:  <alpine.BSF.2.00.0907222232310.3132@teapot.cbhnet> <200907222307.n6MN7YhU012788@apollo.backplane.com> <alpine.BSF.2.00.0907230010250.3132@teapot.cbhnet>

next in thread | previous in thread | raw e-mail | index | archive | help
    TCP will likely work better, for several reasons, not the least of
    which being that the NFS client does not have to estimate a retransmit
    timeout on a rpc-by-rpc basis.  Such estimations fail utterly in the
    face of a large number of concurrent RPCs because latency winds up being
    governed by the disk backlog on the server.  A UDP mount will wind up
    retransmitting even under completely lossless conditions.

    Another reason TCP tends to work better is that UDP uses IP fragmentation
    and IP fragmentation reassembly is not typically in the critical path.
    The desired NFS filesystem block size is 16K (smaller will typically
    reduce performance), so even a 9000 MTU won't help.

    Also use netstat ... not sure what option, I think -x, to determine the
    actual size of the socket buffer being employed for the connection
    (TCP or UDP).  There are multiple internal caps in the kernel and it
    is often not as big as you might have thought it should be.  You want
    a 256KB socket buffer at a minimum for a GigE network.  Smaller works
    (at least for linear transfers), but you lose a lot of RPC concurrency
    from the client.  Again, something that matters more for a linux client
    vs a FreeBSD client.

						-Matt




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200907222340.n6MNe3K5013221>