Date: Mon, 23 Sep 2002 14:08:27 -0500 From: Eric Anderson <anderson@centtech.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-chat@freebsd.org Subject: Re: FreeBSD NFS server using two NICs Message-ID: <3D8F66AB.8020309@centtech.com> References: <3D8A3E52.2090202@centtech.com> <3D8A428B.B96FBE75@mindspring.com> <3D8A458B.2080608@centtech.com> <3D8A4B40.67C8E2A2@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D8F66AB.8020309>