From: Eric Dumazet <eric.dumazet@gmail.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Codel] better mixing in fq_codel
Date: Thu, 30 Aug 2012 16:06:38 -0700 [thread overview]
Message-ID: <1346367998.2586.33.camel@edumazet-glaptop> (raw)
In-Reply-To: <CAA93jw6ayQ3yF89nBRYSVzoBDYms1oDeJfL0TkRaxWm_OWJTNA@mail.gmail.com>
On Thu, 2012-08-30 at 15:59 -0700, Dave Taht wrote:
> I have finally found the source of the issues I was having with htb +
> fq_codel at low bandwidths, and it wasn't htb to the extent I thought
> it was.
>
> It was fq_codel's use of byte quantums, which was resulting in head of
> line blocking for multiple streams.
>
> The undesirable behavior (quantum of 1500)
>
> A new stream, 15 acks (1500 bytes or so)
> B new stream, 4 acks (66 bytes each)
> C new stream, 1 packet, 1500 bytes
>
> Each stream would be delivered in an entire quantum's quantity before
> the next. This is basically something that is nearly unnoticable at
> higher bandwidths, but down here in the slow moving mud, it's quite
> significant. At 1 mbit, 1500 bytes is forever...
>
> Better mixing behavior results from
>
> A 1 packet
> B 1 packet
> C 1 packet (if not larger than quantum)
> A 1 packet ""
> B 1 packet ""
> ...
>
> While I have a patch for this (all 5 lines of it), which does this
> sort of mixing, it crashes under load, but I'll get there. Behavior
> before it crashes is rather nice, where before I was observing
> something like 36 ms of delay with htb for: small packets, "sparse" or
> ANT streams under a variety of loads, it drops below 3ms in the
> general case for those. Both qos-scripts and simple-qos benefit
> hugely.
>
> One of these three sets of changes to fq_codel_dequeue or enqueue is
> dubious. (well, I have a half dozen other patches and fixups to codel
> and fq_codel in the queue too, so have to rip out each). But yea! this
> is the low bandwidth behavior we want!
You dont need a patch, fq_codel has a quantum parameter, default to 1514
Just set it to 256 if you really feel the need.
next prev parent reply other threads:[~2012-08-30 23:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-30 22:59 Dave Taht
2012-08-30 23:06 ` Eric Dumazet [this message]
2012-08-30 23:19 ` Dave Taht
2012-08-31 1:40 ` Eric Dumazet
2012-08-31 2:34 ` Dave Taht
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/codel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1346367998.2586.33.camel@edumazet-glaptop \
--to=eric.dumazet@gmail.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=codel@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
/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