Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] Running Cake at long RTTs
Date: Wed, 28 Oct 2015 17:34:07 +0100	[thread overview]
Message-ID: <87lhankl4w.fsf@toke.dk> (raw)
In-Reply-To: <FC91A343-40E9-4AC7-ABDC-9DCC3FE7A98C@gmx.de> (Sebastian Moeller's message of "Wed, 28 Oct 2015 16:50:56 +0100")

Sebastian Moeller <moeller0@gmx.de> writes:

> Hi Toke,
>
> On Oct 28, 2015, at 16:36 , Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
>> Sebastian Moeller <moeller0@gmx.de> writes:
>> 
>>> Except I requested rtf 120 ms and got 122.7, which admittedly is
>>> close. I know I repeat myself, but on of the is one things that
>>> irritate me in software is if software silently pretends to know
>>> better… Now 122.7 versus 120 might be in the noise, but look at that:
>> 
>> I don't remember from where, but I suspect there's something wrong with
>> the 'change' logic in Cake. Can you try removing the qdisc completely,
>> then re-adding it, rather than doing a straight replace?
>
> Good point:
> moeller@happy-horse:~/CODE/sch_cake> sudo tc-toke qdisc replace dev eth0 root pfifo_fast
> moeller@happy-horse:~/CODE/sch_cake> sudo tc-toke qdisc replace dev eth0 root cake bandwidth 1Mbit besteffort rtt 100ms ; sudo tc-toke -s qdisc

Right, so there's definitely a bug in the 'change' logic.

> Just 95 is not equal to 100 either…

That's also a bug as far as I'm concerned.

> At least in full automatic mode I would have assumed cake would also
> increase the interval according to the available bandwidth in the
> different Tins...

What has the interval got to do with the bandwidth? There's definitely
some value in capping the target to be at least the time it takes to
transmit one MTU's worth of data.

> All the additional parameters are there to tweak and experiment. So I
> argue exposing knobs is not making it difficult to configure as long
> as nobody needs to touch these (I also volunteer to make the tc help
> more specific in that regard…)

If no one needs to touch them, why are they there? At best that will
just make things break when they bitrot.

I can see how getting around the need for the encapsulation variables is
going to be hard; but for the target, I am not sure I see the value in
exposing this for "experimentation". If we are sure that the relation
between target and interval should be fixed (and I'm not entirely
convinced of that yet, but will think about it some more), then exposing
target is just going to enable invalid configurations.

-Toke

  reply	other threads:[~2015-10-28 16:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-27 15:14 Toke Høiland-Jørgensen
2015-10-27 15:16 ` Loganaden Velvindron
     [not found] ` <6499FF74-D13B-4B2E-90E3-D1FDD3FD1468@gmx.de>
2015-10-27 16:50   ` Toke Høiland-Jørgensen
2015-10-27 17:14     ` Sebastian Moeller
2015-10-27 19:04 ` Jonathan Morton
2015-10-27 23:57   ` Toke Høiland-Jørgensen
2015-10-28  9:36     ` Sebastian Moeller
2015-10-28 15:28 ` Sebastian Moeller
2015-10-28 15:36   ` Toke Høiland-Jørgensen
2015-10-28 15:50     ` Sebastian Moeller
2015-10-28 16:34       ` Toke Høiland-Jørgensen [this message]
2015-10-28 17:44         ` Sebastian Moeller
2015-10-29 17:36 ` Kevin Darbyshire-Bryant
2015-10-30 20:30   ` Kevin Darbyshire-Bryant
2015-10-30 21: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/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=87lhankl4w.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=cake@lists.bufferbloat.net \
    --cc=moeller0@gmx.de \
    /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