From owner-freebsd-hackers Fri Jul 19 20:14: 4 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03ADF37B401 for ; Fri, 19 Jul 2002 20:13:57 -0700 (PDT) Received: from garrincha.netbank.com.br (garrincha.netbank.com.br [200.203.199.88]) by mx1.FreeBSD.org (Postfix) with SMTP id 2654343E65 for ; Fri, 19 Jul 2002 20:13:56 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: (qmail 26877 invoked by uid 84); 20 Jul 2002 03:17:48 -0000 Received: from riel@conectiva.com.br by garrincha.netbank.com.br with qmail-scanner-1.01 (. Clean. Processed in 0.717816 secs); 20 Jul 2002 03:17:48 -0000 Received: from 2-110.ctame701-1.telepar.net.br (itdijx@200.193.160.110) by garrincha.netbank.com.br with SMTP; 20 Jul 2002 03:17:47 -0000 Received: from localhost ([IPv6:::ffff:127.0.0.1]:17116 "EHLO localhost") by imladris.surriel.com with ESMTP id ; Sat, 20 Jul 2002 00:12:51 -0300 Date: Sat, 20 Jul 2002 00:12:46 -0300 (BRT) From: Rik van Riel X-X-Sender: riel@imladris.surriel.com To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, Subject: Re: Another go at bandwidth delay product pipeline limiting for TCP In-Reply-To: <200207200245.g6K2jHOh081549@apollo.backplane.com> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 19 Jul 2002, Matthew Dillon wrote: > :It's not too hard actually. Random early drop should be > :enough for incoming packets, just artificially restrict > :the bandwidth to something like 90% of your maximum > :download bandwidth and drop packets that come in too > :fast. > : > :This will cause tcp to slow down to the speed limit you've > :chosen and the ISP queue will never fill up. > > As a receive side mechanism the idea has merit, but I really > dislike artificallly dropping packets as a means of controlling > TCP. It's impossible to know what the effect of the drop would > have on the remote host's protocol stack. I agree it's pretty crude, but it seems to work wonders on my DSL line. I'm using a slightly changed version of the wondershaper script (for Linux)... > Your comment on limiting the bandwidth to 90% of maximum is > really humerous to me! I spent good two hours trying to get > the sender-side algorithm to maintain >90% maximum available > bandwidth. The algorithm I am using winds up being the most stable > at around 88% and it took a bit of messing around to get it > to stabilize at > 90%. I expect a receiver side algorithm would > have the same problem. Absolutely. On my DSL things work best when I limit myself to 220 kbit/s down (from the maximum 256 kbit/s), or about 85% of the bandwidth. For sending I'm using cbq as the top scheduler, dividing traffic in the categories 'interactive', 'bulk' and 'traffic we hate', each of these has a token bucket filter (tbf) leaf scheduler to keep latencies down. Sending is also limited to about 85% of the bandwidth. OTOH, the DSL hardware here seems to be a bit broken, fast uploads seem to interfere with the download and break the download speed. I can run one-way traffic with low latency all the way up to about 95% of the bandwidth... regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message