Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] Other codel decay issues
Date: Mon, 13 Apr 2015 02:22:39 +0300	[thread overview]
Message-ID: <724E2B43-29E4-4344-A910-F41A59ECDF6B@gmail.com> (raw)
In-Reply-To: <CAA93jw7srRMzA01ih67tEhSdZRdKdr44cuG56waDeJ5u1gM+fw@mail.gmail.com>


> On 13 Apr, 2015, at 01:14, Dave Taht <dave.taht@gmail.com> wrote:
> 
> Codel state variable decay is an issue. I did not poke
> into the 8 way set associative cache worked, but...
> 
> Queues empty and fill at lower rates as well, you DO
> want to reuse the codel queue that was going into in
> that case.
> 
> Eric settled on about 3 seconds to gc sch_fq; most
> codel versions reset their state at 1600ms empty.
> 
> You probably want a "fresh" codel queue for each new
> flow, or one borrowing from other existing states.

I took this into account with the set-associative hash design.

The function deliberately tries to keep the same flow in the same queue as much as is reasonable, without flip-flopping a given queue between flows.  The latter is only likely to occur if both flows are fairly sparse, giving Codel little to do on them, or if severe overload is causing collisions.

To help with testing this, I note that the first version of cake was functionally equivalent to fq_codel if you specified “unlimited besteffort” as its options.  Cake3 behaves similarly in this respect, except that now you get the set-associative hash instead of the plain one (and there’s no way to turn that off at runtime).

 - Jonathan Morton


      reply	other threads:[~2015-04-12 23:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-12 22:14 Dave Taht
2015-04-12 23:22 ` Jonathan Morton [this message]

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/cake.lists.bufferbloat.net/

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

  git send-email \
    --in-reply-to=724E2B43-29E4-4344-A910-F41A59ECDF6B@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=cake@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