From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: "Toke Høiland-Jørgensen" <toke@toke.dk>,
"Cake List" <cake@lists.bufferbloat.net>,
"Pete Heist" <peteheist@gmail.com>
Subject: Re: [Cake] lan keyword affects host fairness
Date: Fri, 24 Nov 2017 11:15:35 -0200 [thread overview]
Message-ID: <20171124131534.GA32400@localhost.localdomain> (raw)
In-Reply-To: <11A70C51-8436-46BD-BBD0-8A5E7A2C7AA3@gmx.de>
On Fri, Nov 24, 2017 at 01:06:12PM +0100, Sebastian Moeller wrote:
>
> > On Nov 24, 2017, at 12:21, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> >
> > Dave Taht <dave@taht.net> writes:
> >
> >> Pete Heist <peteheist@gmail.com> writes:
> >>
> >>> On Nov 23, 2017, at 10:44 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
> >>>
> >>> This is most likely an interaction of the AQM with Linux' scheduling
> >>> latency.
> >>>
> >>> At the 'lan' setting, the time comstants are similar in magnitude to the
> >>> delays induced by Linux itself, so congestion might be signalled
> >>> prematurely. The flows will then become sparse and total throughput reduced,
> >>> leaving little or no back-pressure for the fairness logic to work against.
> >>
> >> Agreed.
> >>
> >> man page add:
> >>
> >> At the 'lan' setting(1ms), the time constants are similar in magnitude
> >> to the jitter in the Linux kernel itself, so congestion might be
> >> signalled prematurely. The flows will then become sparse and total
> >> throughput reduced, leaving little or no back-pressure for the fairness
> >> logic to work against. Use the "metro" setting for local lans unless you
> >> have a custom kernel.
> >
> > Erm, doesn't this make the 'lan' keyword pretty much useless? So why not
> > just remove it? Or redefine it to something that actually works? 3ms?
>
> The same applies for datacentre (0.1 ms), no? But I agree, let's not expose these as explicit keywords, one can always use "rtt [100us|1ms]" I assume...
Which should also contain such disclaimer with it.
"Values smaller than 10ms requires special handling.", for example.
Marcelo
next prev parent reply other threads:[~2017-11-24 13:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-23 9:21 Pete Heist
2017-11-23 9:44 ` Jonathan Morton
2017-11-23 10:25 ` Pete Heist
2017-11-23 17:03 ` Dave Taht
2017-11-24 11:21 ` Toke Høiland-Jørgensen
2017-11-24 12:06 ` Sebastian Moeller
2017-11-24 13:15 ` Marcelo Ricardo Leitner [this message]
2017-11-24 13:49 ` Pete Heist
2017-11-24 19:41 ` Pete Heist
2017-11-24 19:48 ` Jonathan Morton
2017-11-24 20:24 ` Pete Heist
[not found] ` <CAJq5cE2eX4AJCPaBL-FW7Oj_afthXKnZn1RHQPH1VBCJfCyXDg@mail.gmail.com>
2017-11-24 20:32 ` Jonathan Morton
2017-11-25 7:18 ` Pete Heist
2017-11-24 20:03 ` Dave Taht
2017-11-24 20:40 ` 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=20171124131534.GA32400@localhost.localdomain \
--to=marcelo.leitner@gmail.com \
--cc=cake@lists.bufferbloat.net \
--cc=moeller0@gmx.de \
--cc=peteheist@gmail.com \
--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