General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Hans-Kristian Bakke <hkbakke@gmail.com>
To: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] Initial tests with BBR in kernel 4.9
Date: Wed, 25 Jan 2017 22:03:14 +0100	[thread overview]
Message-ID: <CAD_cGvExRiWvuKgGuPp6DT2ftG4+ju1hAjXK-C7SXa1xuWfaBA@mail.gmail.com> (raw)
In-Reply-To: <CAD_cGvFnUZenRUh_sOABCqzZejvG_UWw5v0WOwbedTT7f_gbxw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2429 bytes --]

I did some more testing with fq as a replacement of pfifo_fast and it now
behaves just as good. It must have been some strange artifact. My questions
are still standing however.

Regards,
Hans-Kristian

On 25 January 2017 at 21:54, Hans-Kristian Bakke <hkbakke@gmail.com> wrote:

> Hi
>
> Kernel 4.9 finally landed in Debian testing so I could finally test BBR in
> a real life environment that I have struggled with getting any kind of
> performance out of.
>
> The challenge at hand is UDP based OpenVPN through europe at around 35 ms
> rtt to my VPN-provider with plenty of available bandwith available in both
> ends and everything completely unknown in between. After tuning the
> UDP-buffers up to make room for my 500 mbit/s symmetrical bandwith at 35 ms
> the download part seemed to work nicely at an unreliable 150 to 300 mbit/s,
> while the upload was stuck at 30 to 60 mbit/s.
>
> Just by activating BBR the bandwith instantly shot up to around 150 mbit/s
> using a fat tcp test to a public iperf3 server located near my VPN exit
> point in the Netherlands. Replace BBR with qubic again and the performance
> is once again all over the place ranging from very bad to bad, but never
> better than 1/3 of BBRs "steady state". In other words "instant WIN!"
>
> However, seeing the requirement of fq and pacing for BBR and noticing that
> I am running pfifo_fast within a VM with virtio NIC on a Proxmox VE host
> with fq_codel on all physical interfaces, I was surprised to see that it
> worked so well.
> I then replaced pfifo_fast with fq and the performance went right down to
> only 1-4 mbit/s from around 150 mbit/s. Removing the fq again regained the
> performance at once.
>
> I have got some questions to you guys that know a lot more than me about
> these things:
> 1. Do fq (and fq_codel) even work reliably in a VM? What is the best
> choice for default qdisc to use in a VM in general?
> 2. Why do BBR immediately "fix" all my issues with upload through that
> "unreliable" big BDP link with pfifo_fast when fq pacing is a requirement?
> 3. Could fq_codel on the physical host be the reason that it still works?
> 4. Do BBR _only_ work with fq pacing or could fq_codel be used as a
> replacement?
> 5. Is BBR perhaps modified to do the right thing without having to change
> the qdisc in the current kernel 4.9?
>
> Sorry for long post, but this is an interesting topic!
>
> Regards,
> Hans-Kristian Bakke
>

[-- Attachment #2: Type: text/html, Size: 4586 bytes --]

  parent reply	other threads:[~2017-01-25 21:03 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-25 20:54 Hans-Kristian Bakke
2017-01-25 21:00 ` Jonathan Morton
     [not found]   ` <CAD_cGvHKw6upOCzDbHLZMSYdyuBHGyo4baaPqM7r=VvMzRFVtg@mail.gmail.com>
2017-01-25 21:09     ` [Bloat] Fwd: " Hans-Kristian Bakke
     [not found]     ` <908CA0EF-3D84-4EB4-ABD8-3042668E842E@gmail.com>
2017-01-25 21:13       ` [Bloat] " Hans-Kristian Bakke
2017-01-25 21:17         ` Jonathan Morton
2017-01-25 21:20           ` Hans-Kristian Bakke
2017-01-25 21:26             ` Jonathan Morton
2017-01-25 21:29               ` Hans-Kristian Bakke
2017-01-25 21:31                 ` Hans-Kristian Bakke
2017-01-25 21:42                   ` Jonathan Morton
2017-01-25 21:48                   ` Eric Dumazet
2017-01-25 22:03                     ` Hans-Kristian Bakke
2017-01-25 21:03 ` Hans-Kristian Bakke [this message]
2017-01-25 22:01 ` Neal Cardwell
2017-01-25 22:02   ` Neal Cardwell
2017-01-25 22:12     ` Hans-Kristian Bakke
2017-01-25 22:06   ` Steinar H. Gunderson
2017-01-25 22:12     ` Eric Dumazet
2017-01-25 22:23       ` Steinar H. Gunderson
2017-01-25 22:27         ` Eric Dumazet
2017-01-25 22:38   ` Hans-Kristian Bakke
2017-01-25 22:48     ` Neal Cardwell
2017-01-25 23:04       ` Hans-Kristian Bakke
2017-01-25 23:31         ` Hans-Kristian Bakke
2017-01-25 23:33         ` Eric Dumazet
2017-01-25 23:41           ` Hans-Kristian Bakke
2017-01-25 23:46             ` Eric Dumazet
2017-01-25 23:47           ` Hans-Kristian Bakke
2017-01-25 23:53             ` Eric Dumazet
2017-01-25 23:56               ` Hans-Kristian Bakke
2017-01-26  0:10                 ` Eric Dumazet

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/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAD_cGvExRiWvuKgGuPp6DT2ftG4+ju1hAjXK-C7SXa1xuWfaBA@mail.gmail.com \
    --to=hkbakke@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    /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