Date: Wed, 30 Jun 2004 14:13:30 -0400 From: Charles Swiger <cswiger@mac.com> To: Bill Moran <wmoran@potentialtech.com> Cc: questions@freebsd.org Subject: Re: REPOST: Performance problems with FTP Message-ID: <31116F58-CAC1-11D8-9B33-003065ABFD92@mac.com> In-Reply-To: <20040629230817.0f6d230e.wmoran@potentialtech.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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 29, 2004, at 11:08 PM, Bill Moran wrote: > Charles Swiger <cswiger@mac.com> 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. -- -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31116F58-CAC1-11D8-9B33-003065ABFD92>