From owner-freebsd-net Sun Nov 5 15:11: 8 2000 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id 1E48237B4CF for ; Sun, 5 Nov 2000 15:11:06 -0800 (PST) Received: by overlord.e-gerbil.net (Postfix, from userid 1001) id DDFADE4EB9; Sun, 5 Nov 2000 18:11:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by overlord.e-gerbil.net (Postfix) with ESMTP id 8E3F4E4EB8; Sun, 5 Nov 2000 18:11:02 -0500 (EST) Date: Sun, 5 Nov 2000 18:11:02 -0500 (EST) From: "Richard A. Steenbergen" To: David Greenman Cc: freebsd-net@freebsd.org Subject: Re: tcp sendspace/recvspace In-Reply-To: <200011052257.OAA24410@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 5 Nov 2000, David Greenman wrote: > Uh, the negotiated window maximum is the lower of the receiver's advertised > window and the sender's congestion window, so both sides must cooperate for > a larger window to be used. Since FreeBSD is used as both a client and server > platform, I feel it is important to increase both recvspace and sendspace. Not really. Cooperation on both sides is not totally necessary, as the senders congestion window does not depend on the senders sendbuf. A larger sendbuf is only necessary in the face of packet loss recovery. Which is not to say that this isn't valuable and improves performance, but you'll still get your performance gain with only receiver side cooperation. The numbers you're looking for sendbuf wise are at least 2*cwnd. You should take a look at a paper on the subject from SIGCOMM 98, at http://www.psc.edu/networking/papers/auto_abstract.html and the implementation for NetBSD that they have done (as well as other interesting projects) at http://www.psc.edu/networking/research.html. I wouldn't recommend copying their implementation exactly, but they have interesting numbers and graphs on the subject. > Overall I like the idea of a dynamically scaling these, but I'm talking > about the "right now" and not the "next year some time, maybe". I am concerned > about the increased memory use in some applications, but memory is cheap > these days and getting cheaper. Really the only issue I see is that some > people may not be prepared to tune there kernel configs to allow for the > increased network buffer use. Memory isn't the issue, kernel memory is the issue, as well as behavior in the face of network outages. -- Richard A Steenbergen http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message