Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] Long-RTT broken again
Date: Tue, 3 Nov 2015 20:24:50 +0100	[thread overview]
Message-ID: <907246CB-2510-4217-B13C-DDFE0909D1BC@gmx.de> (raw)
In-Reply-To: <CAJq5cE0pWJ68tyZp6fi2xqtNcEwofHnZChHpNK492nud9Qjnjw@mail.gmail.com>

Hi Jonathan,

On Nov 3, 2015, at 20:17 , Jonathan Morton <chromatix99@gmail.com> wrote:

> Conceptually, I think limiting actual memory usage is the right thing to do.  

	I agree ;) but I am coming at this from the avoid OOM direction anyway; I believe Toke’s point for people coming from the BDP angle is equally valid (if less important to me personally).

> Ideally, the allocations would turn out closer to the actual packet sizes, but by watching the allocated size, we will automagically take advantage of improvements in this area - which must happen elsewhere in the kernel.

	But this is acknowledging there is a discrepancy and the punting, turning it into someone else’s problem, no?

> 
> Limiting total on-wire packet bytes is nice from a theoretical point of view, but we don't live in a theoretical world.  The performance discrepancy shouldn't be as big as it is.

	But this is about honoring BDP calculations for worst case buffering scenarios where the sender dumps all packets for a whole transfer period in one instantaneous burst (well almost); this seems well documented in the literature and hence might be something users might actually want to do...

> 
> Limiting packet count is wrong and awful and we shouldn't do that, even if everyone else does.  The fact that counting allocated bytes behaves the same way at the moment is unfortunate.

	Why? The fact that they are correlated also allows to limit by allocated size, since the correlation is directionally insensitive, so to speak, we can always argue that the packet fans just need a proportionality constant and be done with ;). I guess this needs a clear name than simply limit to avoid confusing people who already know other qdiscs and their behavior.

Best Regards
	Sebastian

> 
> - Jonathan Morton


  reply	other threads:[~2015-11-03 19:24 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-02 16:53 Toke Høiland-Jørgensen
2015-11-02 18:29 ` Sebastian Moeller
2015-11-03  1:39   ` Jonathan Morton
2015-11-03  8:20     ` Sebastian Moeller
2015-11-03  8:25       ` Jonathan Morton
2015-11-03  8:34         ` Sebastian Moeller
2015-11-03 10:29           ` Kevin Darbyshire-Bryant
2015-11-03 11:08             ` Sebastian Moeller
2015-11-03 11:45               ` Toke Høiland-Jørgensen
2015-11-03 11:57       ` Toke Høiland-Jørgensen
2015-11-03 12:41         ` Sebastian Moeller
2015-11-03 11:50     ` Toke Høiland-Jørgensen
2015-11-03 16:43       ` Jonathan Morton
2015-11-03 17:05         ` Toke Høiland-Jørgensen
2015-11-03 17:11           ` Sebastian Moeller
2015-11-03 17:25             ` Toke Høiland-Jørgensen
2015-11-03 17:31               ` Jonathan Morton
2015-11-03 17:33                 ` Toke Høiland-Jørgensen
2015-11-03 17:46                   ` Sebastian Moeller
2015-11-03 17:49                     ` Toke Høiland-Jørgensen
2015-11-03 17:52                       ` Sebastian Moeller
2015-11-03 17:54                         ` Toke Høiland-Jørgensen
2015-11-03 17:57                           ` Sebastian Moeller
2015-11-03 17:59                             ` Toke Høiland-Jørgensen
2015-11-03 18:06                               ` Sebastian Moeller
2015-11-03 19:17                                 ` Jonathan Morton
2015-11-03 19:24                                   ` Sebastian Moeller [this message]
2015-11-05 14:36         ` Toke Høiland-Jørgensen
2015-11-05 19:30           ` Jonathan Morton
2015-11-06 11:00             ` Toke Høiland-Jørgensen
2015-11-06 14:15               ` Toke Høiland-Jørgensen
2015-11-06 15:09                 ` Toke Høiland-Jørgensen
2015-11-07  5:02                 ` Jonathan Morton
2015-11-07  5:16                   ` Dave Taht
2015-11-07  6:49                     ` Jonathan Morton
2015-11-07  8:48                   ` Toke Høiland-Jørgensen
2015-11-07 10:51                     ` Jonathan Morton
2015-11-07 13:06                       ` Jonathan Morton
2015-11-07 13:42                         ` Toke Høiland-Jørgensen
2015-11-07 16:34                         ` Toke Høiland-Jørgensen
2015-11-07 13:44                       ` Toke Høiland-Jørgensen
2015-11-07 15:08                       ` Sebastian Moeller
2015-11-07 16:24                         ` Toke Høiland-Jørgensen
2015-11-07 18:25                           ` Sebastian Moeller
2015-11-07 19:32                           ` Kevin Darbyshire-Bryant
2015-11-08 16:29                             ` Dave Taht
2015-11-11 10:23                               ` Kevin Darbyshire-Bryant

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=907246CB-2510-4217-B13C-DDFE0909D1BC@gmx.de \
    --to=moeller0@gmx.de \
    --cc=cake@lists.bufferbloat.net \
    --cc=chromatix99@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