General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] curious.....
Date: Sun, 8 Dec 2013 08:51:41 -0800	[thread overview]
Message-ID: <CAA93jw6PmaCLsEyAb3yHX9FxBepHt+CN=+XV+nAQ11KShpu=7Q@mail.gmail.com> (raw)
In-Reply-To: <878uvvcwqh.wl%jch@pps.univ-paris-diderot.fr>

On Sun, Dec 8, 2013 at 5:12 AM, Juliusz Chroboczek
<jch@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,
no nat.

> 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
hardware.

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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

  parent reply	other threads:[~2013-12-08 16:51 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-03 18:40 Outback Dingo
2013-12-03 22:25 ` Kenyon Ralph
2013-12-04  0:25   ` Outback Dingo
2013-12-04  0:38     ` Dave Taht
2013-12-06 17:19       ` Juliusz Chroboczek
2013-12-06 18:15         ` Dave Taht
2013-12-07 11:24           ` Sebastian Moeller
2013-12-10 19:05             ` Dave Taht
2013-12-11 10:44               ` Sebastian Moeller
2013-12-07 12:59           ` Juliusz Chroboczek
2013-12-08  1:27             ` Steinar H. Gunderson
2013-12-08  5:24               ` Mikael Abrahamsson
2013-12-08 11:00                 ` Mark Constable
2013-12-08 14:01                   ` Outback Dingo
2013-12-08 14:03                     ` Outback Dingo
2013-12-08 16:44                     ` Mark Constable
2013-12-08 19:00                       ` Sebastian Moeller
2013-12-08 13:12                 ` Juliusz Chroboczek
2013-12-08 16:46                   ` Jonathan Morton
2013-12-08 16:51                   ` Dave Taht [this message]
2013-12-08 17:56                     ` Juliusz Chroboczek
2013-12-08 21:05                       ` Jonathan Morton
2013-12-08 14:22                 ` Aaron Wood
2013-12-08 14:41                 ` Jim Gettys
2013-12-08 10:40             ` Sebastian Moeller
2013-12-08 13:25               ` Juliusz Chroboczek
2013-12-08 16:26                 ` Sebastian Moeller
2013-12-08 17:47                   ` Juliusz Chroboczek
2013-12-08 19:02                     ` Sebastian Moeller
2013-12-22  1:38                       ` Dan Siemon
2013-12-22  3:46                         ` Stephen Hemminger
2013-12-08 19:01                   ` Jonathan Morton
2013-12-08 19:21                     ` Sebastian Moeller
2013-12-08 16:01               ` Neil Davies
2013-12-08 20:41 Hal Murray
2013-12-08 23:16 ` Stephen Hemminger
2013-12-09  9:51 ` Sebastian Moeller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAA93jw6PmaCLsEyAb3yHX9FxBepHt+CN=+XV+nAQ11KShpu=7Q@mail.gmail.com' \
    --to=dave.taht@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=jch@pps.univ-paris-diderot.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox