From owner-freebsd-net Tue Nov 7 14:35: 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 7878337B479 for ; Tue, 7 Nov 2000 14:35:05 -0800 (PST) Received: by overlord.e-gerbil.net (Postfix, from userid 1001) id 6A99DE4EB9; Tue, 7 Nov 2000 17:34:53 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by overlord.e-gerbil.net (Postfix) with ESMTP id 56A57E4EB8; Tue, 7 Nov 2000 17:34:53 -0500 (EST) Date: Tue, 7 Nov 2000 17:34:53 -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: > 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 Its nowhere near so far away. Infact if you're interested, here's the current holdup. The auto-tuned socket buffer size is designed to take feedback from the cwnd, to determine what the socket "wants". But in a low memory situation, the socket may not always be able to get what it wants. In order to determine how much it "gets", one should be fair and consider the demands of all other sockets. The PSC implementation does this by periodically (on slowtimo) scanning through all tcp sockets, and calculating a fair value per socket. http://www.psc.edu/publications/tech_reports/fairshare/fairshare.html http://www.psc.edu/networking/papers/sigcomm98/sld018.htm http://www.psc.edu/networking/papers/sigcomm98/sld016.htm This obviously has performance and locking implications, and probably isn't the easiest way to do things. The method that I'm considering most heavily now is eliminating the slowtimo called scan, seperating the demands for memory into "easy" to fill aka we can give it everything it wants, and "hard" to fill, and then calculating ratios of available / requested to determine how much the sockets can get... In order for this to be effective it would need to be driven down to sbappend() and done on a per packet basis though. I'm really not happy with any solution so far. -- 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