From owner-freebsd-questions@FreeBSD.ORG Fri Jul 2 12:13:14 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CACD916A4CE for ; Fri, 2 Jul 2004 12:13:14 +0000 (GMT) Received: from internet.potentialtech.com (h-66-167-251-6.phlapafg.covad.net [66.167.251.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8098643D39 for ; Fri, 2 Jul 2004 12:13:14 +0000 (GMT) (envelope-from wmoran@potentialtech.com) Received: from working.potentialtech.com (pa-plum-cmts1e-68-68-113-64.pittpa.adelphia.net [68.68.113.64]) by internet.potentialtech.com (Postfix) with ESMTP id E8FB969A39; Fri, 2 Jul 2004 08:12:19 -0400 (EDT) Date: Fri, 2 Jul 2004 08:12:18 -0400 From: Bill Moran To: Charles Swiger Message-Id: <20040702081218.22bb997b.wmoran@potentialtech.com> In-Reply-To: <31116F58-CAC1-11D8-9B33-003065ABFD92@mac.com> References: <20040629140231.7b57dedf.wmoran@potentialtech.com> <1187B403-C9FC-11D8-99F8-003065ABFD92@mac.com> <20040629153855.300b3888.wmoran@potentialtech.com> <1133CD52-CA07-11D8-99F8-003065ABFD92@mac.com> <20040629230817.0f6d230e.wmoran@potentialtech.com> <31116F58-CAC1-11D8-9B33-003065ABFD92@mac.com> Organization: Potential Technologies X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: questions@freebsd.org Subject: Re: REPOST: Performance problems with FTP X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2004 12:13:15 -0000 Charles Swiger wrote: > On Jun 29, 2004, at 11:08 PM, Bill Moran wrote: > > Charles Swiger wrote: > >> Well, that does tend to rule out a bunch of issues. Have you tried > >> changing the MTU of the FreeBSD box down to 1400 or so (or even 512), > >> just to see whether that does anything? > > > > OK. I've had a bit of success here ... > > > > By setting the MTU down to ~650, I get the best performance I've seen > > with this setup (about 27k/sec ... which isn't too bad) I set > > "SocketOptions maxseg 650" in the proftpd.conf file for now, which > > seems > > to help a good bit. > > Bingo, found something! All should be easy from here on out... :-) > > > But I'm really confused. Why does reducing the MTU improve > > performance? > > I would have thought it would hurt performance by increasing the # of > > packets, thus increasing overhead. > > Using a smaller MTU normally does hurt performance, as you have to send > more packets (as you've said) and because the overhead (ratio of packet > header size to data size) becomes larger. However, using an MTU which > is too big means packets have to be fragmented and reassembled, which > slows things down a lot, too. > > Anyway, it is likely that one of the networks involved in the > connection has a smaller MTU than normal, which means large data > packets get fragmented, resulting in delays. FTP data connections tend > to show this more than scp does, as the latter seems to vary the packet > size more: perhaps a result of using compression/encryption within the > SSH protocol. > > > I did some captures using Ethereal, and I'm seeing a weird pause (with > > the MTU at the default) where the client will send three packets, > > there'll > > be a pause, then the ack comes back, then three packets, pause, ack ... > > That rings a bell. Are you using path MTU discovery? Is some firewall > in place that might be blocking ICMP_UNREACH_NEEDFRAG messages (ICMP > type 3, subtype 4)? > > You should try doing a traceroute which can do pMTU testing; I'm not > sure whether the stock FreeBSD traceroute can do this, but a search > ought to dig up something. Well ... this has turned up the weirdest stuff I've seen in a while! Seems like you're right about PMTU ... but the problem is pretty complex overall. The max PMTU seems to change periodically. It was around 800bytes early yesterday when I checked it. Then, late yesterday, when I was going to track down exactly where the problem was, the PMTU went up to the same MTU my cable connection uses, thus I couldn't use this connection for testing as I couldn't get packets out of it without them fragmenting. (on the flip side, it seems to be _my_ ISP that's rejecting ICMP packets, so I'll have to complain to them) Anyway ... your advice, in addition to a number of resource I found on the web by searching for PMTU, has isolated the problem. Figuring out how to fix it will be another thing altogether. Thanks. -- Bill Moran Potential Technologies http://www.potentialtech.com