dave.taht at gmail.com
Sun Dec 8 11:51:41 EST 2013
On Sun, Dec 8, 2013 at 5:12 AM, Juliusz Chroboczek
<jch at pps.univ-paris-diderot.fr> wrote:
>>> FYI: Norway has at least two entirely distinct ISPs that offer 200
>>> Mbit/sec or more.
>> Sweden has a bunch of them as well, 1000/100 is quite common,
>> 1000/1000 can be had
> I stand corrected.
>> The comment about the WNDR3800 not being able to push this is of
>> course relevant,
> I think that the WNDR3800 should be able to push a gigabit, even with
> NAT. Dave's point, as far as I understand, is that the WNDR is not
No, it tops out at about 330Mbit/sec currently with no firewall rules,
> able to push a gigabit *through fq_codel*, so he's looking for ways to
> automatically replace fq_codel with something simpler at higher rates.
No. aqm-scripts can't push 110KB/sec through *HTB*. The rate limiter is the
biggest cpu pig in the system.
fq_codel itself barely shows up on benchmarks vs red OR pfifo_fast.
It's overhead is trivial. It's on by default on the ethernet and wifi
interfaces, so at bursty line rates you see it come into play. So htb
is the problem.
What I was thinking about was taking the 3 tier structure of the
current aqm-scripts system, turning it into something more drr-like
and adding support for rate limiting directly to it, which I hope
would give a larger outer limit for rate shaping than htb on this
There are some tweakable knobs for htb that might help, notably
setting a larger quantum at higher rates.
I've had various variants of this idea running off and on for the last
year, (been calling it "cake"). I'm aware that google has something
similar already so I keep hoping they will release theirs...
I have some feedback on some of the lines of thought expressed on this
thread earlier but I have to jump on a train now. Notably it seems few
have internalized what the "sparse stream" optimization does for
things like voip.
> My point is that, Scandinavians excepted, most people don't have
> multigigabit links at home, and so Dave's scripts should still be
> useful even if they top at 80 Mbit. Of course, (1) optimising fq_codel,
> (2) making fq_codel do something fast at high data rates, and
> (3) finding a successor to the WNDR3800 are all laudable goals.
> -- Juliusz
> Bloat mailing list
> Bloat at lists.bufferbloat.net
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
More information about the Bloat