From: Sebastian Moeller <moeller0@gmx.de>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] Running Cake at long RTTs
Date: Tue, 27 Oct 2015 18:14:23 +0100 [thread overview]
Message-ID: <5FC9444D-C51A-4F81-BBE5-38A58E238E24@gmx.de> (raw)
In-Reply-To: <8737wwmf1h.fsf@toke.dk>
Hi Toke,
On Oct 27, 2015, at 17:50 , Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Sebastian Moeller <moeller0@gmx.de> writes:
>
>>> - Turn the hard packet queue size into a lower bound rather than an
>>> upper bound.
>>
>> This seems dangerous for low memory configurations?
>
> Well, yeah, the max packet count allowed can be higher this way, but I
> guess the only sane answer to that is "don't configure cake for 100Mbit
> and 1s+ of latency if you don't have the memory to spare”.
What about cake honoring it as a hard limit but complaining to syslog, if cake deems the limit too low? If I recall correctly, having a qdisc OOM a router basically functionally bricks the router (unit the next reboot) or forces a reboot, both not ideal.
>
> Having the (now lower) bound be a bit lower than it is currently may be
> a good idea, but not sure what it should be... The current 10240 matches
> fq_codel.
Oh, I guess that is fine, it just means that for low memory devices we need to teach sqm-scripts to reign in a bit...
>
>>> - Scale the target to be 1/16th of the interval.
>>
>> Codel theory claims 5-10%, so 1/20 to 1/10, so it seems you
>> confirm the theory, not sure why cake did not do this as a
>> default… rem, what actually was cake setting target to? Asked
>> differently how sensitive to target being exactly 1/16th was the
>> throughput?
>
> Yup. 1/16th has the benefit of being implementable as a 4bit shift :)
So is 1/8th ;) just curious, which values did you try? Codel RFC argues for 5-10% with 10% giving ever so slightly more bandwidth, while 5% keeps latency under load increase a bit smaller. But I really like that reality fits theory here, chalk this one up for code;l’s designers ;)
>
> Before, the target was hard-coded as 5 ms; so this was definitely an
> oversight.
Not sure, we had discussed this and Jonathan argued that it requires empiric testing if I recall correctly, exactly what you have done ;)
I still believe that for any automatic choice cake does there should be a manual override option for experimentation, most urgently a manual target specification that will override all automatic optimizations. Well, just as for the queue max size I believe cake should complain if it thinks things are unreasonable but still do follow the users request if non impossible…
Best Regards
Sebastian
>
> -Toke
next prev parent reply other threads:[~2015-10-27 17:14 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 [this message]
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
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=5FC9444D-C51A-4F81-BBE5-38A58E238E24@gmx.de \
--to=moeller0@gmx.de \
--cc=cake@lists.bufferbloat.net \
--cc=toke@toke.dk \
/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