From owner-freebsd-questions Sun Dec 31 21:04:01 1995 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA08091 for questions-outgoing; Sun, 31 Dec 1995 21:04:01 -0800 (PST) Received: from mail.barrnet.net (mail.barrnet.net [131.119.246.7]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id VAA08073 Sun, 31 Dec 1995 21:03:57 -0800 (PST) Received: from silver.sms.fi (silver.sms.fi [194.111.122.1]) by mail.barrnet.net (8.7.1/MAIL-RELAY-LEN) with SMTP id AAA04691; Tue, 26 Dec 1995 00:21:39 -0800 (PST) Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id KAA27158; Tue, 26 Dec 1995 10:01:50 +0200 Date: Tue, 26 Dec 1995 10:01:50 +0200 Message-Id: <199512260801.KAA27158@silver.sms.fi> From: Petri Helenius To: davidg@Root.COM Cc: questions@freebsd.org, wollman@freebsd.org Subject: Re: Unpleasant scrolling behaviour on 2.1.0 (fwd) In-Reply-To: <199512260021.QAA05890@corbin.Root.COM> References: <199512252127.XAA26484@silver.sms.fi> <199512260021.QAA05890@corbin.Root.COM> Sender: owner-questions@freebsd.org Precedence: bulk David Greenman writes: > The loopback MTU has been at 16K or greater since Garrett Wollman first > changed it to 64k back in FreeBSD 1.1. I changed it from 64K to 16K back in > March of this year because of some bad interaction that 64K has with the > socket layer. As for "stop-and-go", no, having the MTU at 16k doesn't by > itself cause this - especially since the window size is significantly larger > than that. You can use a variety of network tools to verify this. The window size is (by default) at 16384. Just run tcpdump and you'll soon figure this out. > It should probably be lowered because of bugs in the networking code. This > has likely started to become a problem recently because of some bugs fixes > in areas that indirectly affect the Nagel algorithm. 'ttcp -t localhost' still > gives very good results for the 16K MTU, so it's not completely broken. It's Nagle. > It's very presumptuous to assume that "non-networking skilled individuals" > were involved in this change. Quite the contrary. If you want to be helpful, > then I'd suggest making useful comments about what you think the MTU should be > changed to and why you think it should be changed. Your comments will > otherwise only alienante you and cause people to ignore you. > The MTU should be half or less of the default window size. I would recommend values in the range of 5k to get effective streaming regardless of the application and specific system scheduling load. Calculate something like TCP_MSS < MTU < (TCP_WIN/3) and you'll be safe. On the helpfulness side, I'd tried to raise discussion on this topic a couple of times before, until I threw the flame above, nobody cared. Pete