From owner-freebsd-chat Mon Sep 23 12: 9: 4 2002 Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F82E37B401 for ; Mon, 23 Sep 2002 12:09:02 -0700 (PDT) Received: from proxy.centtech.com (moat.centtech.com [207.200.51.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39D6543E4A for ; Mon, 23 Sep 2002 12:09:01 -0700 (PDT) (envelope-from anderson@centtech.com) Received: from sprint.centtech.com (sprint.centtech.com [10.177.173.31]) by proxy.centtech.com (8.11.6+Sun/8.11.6) with ESMTP id g8NJ8sk03921; Mon, 23 Sep 2002 14:08:55 -0500 (CDT) Received: (from root@localhost) by sprint.centtech.com (8.11.6+Sun/8.11.6) id g8NJ8sj28523; Mon, 23 Sep 2002 14:08:54 -0500 (CDT) Received: from centtech.com (electron [204.177.173.173]) by sprint.centtech.com (8.11.6+Sun/8.11.6) with ESMTP id g8NJ8pg28516; Mon, 23 Sep 2002 14:08:51 -0500 (CDT) Message-ID: <3D8F66AB.8020309@centtech.com> Date: Mon, 23 Sep 2002 14:08:27 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Terry Lambert Cc: freebsd-chat@freebsd.org Subject: Re: FreeBSD NFS server using two NICs References: <3D8A3E52.2090202@centtech.com> <3D8A428B.B96FBE75@mindspring.com> <3D8A458B.2080608@centtech.com> <3D8A4B40.67C8E2A2@mindspring.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Terry Lambert wrote: > Eric Anderson wrote: > >>>It would help if you gave a URL into the PR database for your >>>problem report, if you are going to reference it this way. >> >>Right you are: >> >>It's PR# 35151: >>http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/35151 > > > Are the clients connectiong via TCP or UDP? There is a common > problem with UDP, with clients connecting with a read/write size > that is much larger than the MTU (mostly Linux clients), so you > end up getting a crud-load of UDP packets sitting in the reassembly > buffer for long periods of tiem, without a frag retansmit mechanism > other than resending the whole of the data. Clients are UDP.. > The correct fixes for this are one of: > > o Use TCP instead > > o Drop the read/write size to less than or equal to the > amount of data that can be sent in a single MTU. > > Basically, large UDP datagrams that get broken up are someone > wanting the benefits of having a large window, without using a > windowed protocol. > > The long term correction for this would probably be to do IP > based RED queueing of requests (plain RED would result in the > ability to DOS it with partial UDP requests, and saturation > dropping of the reassembly queue would permit you to DOS real > data out of the reassembly queue with "two packet, second half" > attacks, at the expense of much > 2 packet reassemblies -- a > statistical attack, in both cases). > > > Another thing to look at is to do a dump of the raw packets on > the wires; it may be that the Sun machine is sending the requests > at random, with the multipath, and only accepting responses that > come from the "right" place in response, retrying the failed ones > forever, or until it gets a response it will accept. A dump of > the packets on the wire should tell you if this is happening. > This theory fits well with the delayed ramp-up, and the additional > delay, if soft updates are disabled. > > > Other than those theories, and what to look for, it's easier to > point you back at Matt. 8-). Ok.. I'll give the read/write size shrinkage a try - Do you know what should work? mtu's from ifconfig show 1500 - that seems awefully small. Eric -- ------------------------------------------------------------------ Eric Anderson Systems Administrator Centaur Technology The moon may be smaller than Earth, but it's further away. ------------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message