Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: Dave Taht <dave@taht.net>, Pete Heist <peteheist@gmail.com>,
	Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] lan keyword affects host fairness
Date: Fri, 24 Nov 2017 13:06:12 +0100	[thread overview]
Message-ID: <11A70C51-8436-46BD-BBD0-8A5E7A2C7AA3@gmx.de> (raw)
In-Reply-To: <87609zapmt.fsf@toke.dk>


> 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...


> 
> -Toke
> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake


  reply	other threads:[~2017-11-24 12:06 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 [this message]
2017-11-24 13:15           ` Marcelo Ricardo Leitner
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=11A70C51-8436-46BD-BBD0-8A5E7A2C7AA3@gmx.de \
    --to=moeller0@gmx.de \
    --cc=cake@lists.bufferbloat.net \
    --cc=dave@taht.net \
    --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