Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: erik.taraldsen@telenor.com
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] ER-X now running cake, thanks for the help. :)
Date: Fri, 5 May 2017 16:06:19 +0200	[thread overview]
Message-ID: <F4C3DA9A-E834-4212-9346-D46FCB85318E@gmx.de> (raw)
In-Reply-To: <1493992526496.9641@telenor.com>

Hi Erik,


> On May 5, 2017, at 15:55, erik.taraldsen@telenor.com wrote:
> 
>> Fra: Sebastian Moeller <moeller0@gmx.de>
> 
>> .. snip <good explanations and tips> 
>> One problem with the unelastic load is that as far as I can tell no flow on the open internet is 
>> allows/assumed to behave like that (isn’t the default tcp-friendly, and inelastic DOS traffic is 
>> essentially out-lawed?)
> 
> You are right in that single stream udp without any feedback is a quite unrealistic load.  It is however usually a good indicator of possible trouble with bufferbloat.  When I get delays in the multiple seconds range there usually is no point in running more realistic tests such as flent, so I tend to start with that udp test before setting up a lab.  Current record found in production systems is 34 seconds.

	I beg to differ somewhat. With fq_codel and cake the high-bandwidth in-elastic UDP flow (heck an in-elastic TCP flow would be the same) really is just testing the DOS case and effectively probing the worst case memory buffer behind the AQM. So I believe this is a valid test, but it is not a show-stopper if this test shows deep buffers. Netalyzr basically does that (and it also measures for short durations so that fq_codel/cake have problems ramping their drop probability high enough in time to make dent into the load). Under normal operating conditions however that buffer will never fill up and hence can be considered harmless (or actually helpfull, as it allows to straighten out bursty traffic).

Best Regards
	Sebastian


> 
> I'll redo the test using flent in the lab next week, using both fq_codel and cake.
> 
> -Erik


      parent reply	other threads:[~2017-05-05 14:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-05 13:00 erik.taraldsen
2017-05-05 13:20 ` Toke Høiland-Jørgensen
2017-05-05 13:20 ` Sebastian Moeller
2017-05-05 13:55   ` erik.taraldsen
2017-05-05 13:59     ` Toke Høiland-Jørgensen
2017-05-05 14:30       ` erik.taraldsen
2017-05-05 15:23         ` Toke Høiland-Jørgensen
2017-05-05 17:12           ` erik.taraldsen
2017-05-05 19:29             ` Neil Shepperd
2017-05-05 14:06     ` Sebastian Moeller [this message]

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=F4C3DA9A-E834-4212-9346-D46FCB85318E@gmx.de \
    --to=moeller0@gmx.de \
    --cc=cake@lists.bufferbloat.net \
    --cc=erik.taraldsen@telenor.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