Skip site navigation (1)Skip section navigation (2)
From:      Rik van Riel <riel@conectiva.com.br>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        freebsd-hackers@FreeBSD.ORG, <freebsd-net@FreeBSD.ORG>
Subject:   Re: Another go at bandwidth delay product pipeline limiting for TCP
Message-ID:  <Pine.LNX.4.44L.0207200005190.12241-100000@imladris.surriel.com>
In-Reply-To: <200207200245.g6K2jHOh081549@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.44L.0207200005190.12241-100000>