Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Andy Furniss <adf.lists@gmail.com>
To: Jim Gettys <jg@freedesktop.org>
Cc: xnor <xnoreq@gmail.com>, David Lang <david@lang.hm>,
	Cake@lists.bufferbloat.net
Subject: Re: [Cake] cake default target is too low for bbr?
Date: Mon, 8 May 2017 11:37:08 +0100	[thread overview]
Message-ID: <e1c3ded5-72ea-6d9c-5005-63055ddc8c43@gmail.com> (raw)
In-Reply-To: <CAGhGL2CZ5RsRoQym9Lots0vsuNN+NL7MBwFHd=Zq3p7_cSUThw@mail.gmail.com>

Jim Gettys wrote:
> On Thu, May 4, 2017 at 6:22 AM, Andy Furniss <adf.lists@gmail.com> wrote:
> 
>> Jim Gettys wrote:
>>
>>> On Wed, May 3, 2017 at 5:50 AM, Andy Furniss <adf.lists@gmail.com>
>>> wrote:
>>>
>>> Andy Furniss wrote:
>>>>
>>>> Andy Furniss wrote:
>>>>>
>>>>> b) it reacts to increase in RTT. An experiment with 10 Mbps
>>>>> bottleneck,
>>>>>
>>>>>> 40 ms RTT and a typical 1000 packet buffer, increase in RTT
>>>>>>> with BBR is ~3 ms while with cubic it is over 1000 ms.
>>>>>>>
>>>>>>>
>>>>>> That is a nice aspect (though at 60mbit hfsc + 80ms bfifo I
>>>>>> tested with 5 tcps it was IIRC 20ms vs 80 for cubic). I
>>>>>> deliberately test using ifb on my PC because I want to pretend
>>>>>> to be a router - IME (OK it was a while ago) testing on eth
>>>>>> directly gives different results - like the locally generated
>>>>>> tcp is backing off and giving different results.
>>>>>>
>>>>>>
>>>>> I retested this with 40ms latency (netem) with hfsc + 1000 pfifo
>>>>> on ifb.
>>>>>
>>>>>
>>>> So, as Jonathan pointed out to me in another thread bbr needs fq
>>>> and it seems fq only wotks on root of a real eth, which means thay
>>>> are invalid tests.
>>>>
>>>>
>>> ​Specifically, BBR needs packet pacing to work properly: the
>>> algorithm depends on the packets being properly paced.
>>>
>>> Today, fq is the only qdisc supporting pacing.
>>>
>>> The right answer would be to add packet pacing to cake/fq_codel
>>> directly. Until that is done, we don't know how BBR will work in our
>>> world. - Jim​
>>>
>>
>> I guess you mean so cake could be used on egress of sender (in place of
>> fq)?
>>
> 
> ​Yes.
> ​
> 
>>
>> That's not really the test that I intend to do, which is more like -
>>
>> [boxA bbr+fq] -> [boxB simulate ISP buffer] -> [boxC cake ingress shape]
>> a bit lower than "line" rate and see how much "ISP" buffer gets filled.
>>
>> Also compare bbr, cubic and netem different rtts etc.
> 
> 
> ​Ok.  The usual warnings about netem being dangerous apply, though netem
> can be useful if run on a separate machine.  Netem is an attractive
> nuisance, but has caused lots of results to be ultimately useless....  Be
> careful.
>                                - Jim

Yea, I saw the warning about netem on the website - tricky as I would
need 4 boxes to really isolate it, and I've only got three, so it's not
ideal.

I tested with it delaying acks on ingress of sender which had fq on 
egress. Also did some tcpdumps with different setups to see if it was
clumping acks - it seemed smooth.

With this setup my results are much the same as before = bbr is harder
to shape on ingress vs cubic, the longer the rtt to sender the worse it
is.

I was testing 18mbit dsl sim with mainly 16mbit ingress. Repeatedly
grabbing 1 or 2 meg files (like dash) spikes latency every time.
With rtt of 40ms unshaped it will burst to 80+ms, 16mbit behind 18mbit
spikes 50ms. IIRC to get spikes below 20ms I needed 12mbit = too low.

For continuous downloads, after initial spike a single tcp wasn't too 
bad, even 5 can be controlled latency wise at 16mbit.

The problem with 5 vs 1 is the number of drops, 1 not too bad, but 5
will drop 1/10 so tcp ends up sacking almost per packet, which is not
good for those with limited upstream.

ECN marks more packets than would be dropped, almost all in the 5 case
so also causes many upstream acks.

This is with cakes ingress parameter and default rtt of 100ms.

Changing to 300ms does reduce the drops/marks as in my previous post,
but it makes controlling the startup spikes slightly less effective -
though without going really low they weren't controlled very well anyway.


  reply	other threads:[~2017-05-08 10:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.435.1493406198.3609.cake@lists.bufferbloat.net>
2017-04-28 21:11 ` xnor
2017-04-28 21:29   ` David Lang
2017-04-28 21:54     ` Andy Furniss
2017-04-28 22:02     ` xnor
2017-04-28 22:26       ` Andy Furniss
2017-04-28 23:52         ` Andy Furniss
2017-04-28 23:54           ` Andy Furniss
2017-05-03  9:50           ` Andy Furniss
2017-05-04  2:13             ` Jim Gettys
2017-05-04 10:22               ` Andy Furniss
2017-05-04 17:40                 ` Jim Gettys
2017-05-08 10:37                   ` Andy Furniss [this message]
2017-04-29  4:32         ` Jonathan Morton
2017-04-29 10:31           ` Andy Furniss
2017-04-28 19:03 Andy Furniss
2017-04-28 20:45 ` [Cake] " Andy Furniss

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=e1c3ded5-72ea-6d9c-5005-63055ddc8c43@gmail.com \
    --to=adf.lists@gmail.com \
    --cc=Cake@lists.bufferbloat.net \
    --cc=david@lang.hm \
    --cc=jg@freedesktop.org \
    --cc=xnoreq@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