Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Pete Heist <pete@eventide.io>
Cc: Dave Taht <dave.taht@gmail.com>, Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] fairness vs RTT
Date: Tue, 17 Apr 2018 10:24:44 +0200	[thread overview]
Message-ID: <871sfe5jg3.fsf@toke.dk> (raw)
In-Reply-To: <340857DC-FAA7-411B-ABDE-DEC3FC6238D9@eventide.io>

Pete Heist <pete@eventide.io> writes:

>> On Apr 16, 2018, at 11:23 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> 
>>> I remember that fairness behavior at low RTTs (< 20ms) needed to be
>>> either improved or documented, and don’t see anything about that in
>>> the man page in the tc-adv repo thus far. Summarizing the host
>>> isolation results at
>>> http://www.drhleny.cz/bufferbloat/cake/round2/#hostiso_cake_{rtt}_{qos-id}
>>> <http://www.drhleny.cz/bufferbloat/cake/round2/#hostiso_cake_%7Brtt%7D_%7Bqos-id%7D>:
>>> 
>>> RTT: fairness (1.0 == perfect fairness)
>>> ---
>>> 100us: 2.22
>>> 1ms: 1.7
>>> 2ms: 1.6
>>> 3ms: 1.42
>>> 5ms: 1.31
>>> 8ms: 1.16
>>> 10ms: 1.12
>>> 20ms: 1.02
>>> 40ms: 1.017
>> 
>> Erm, what's the metric and which data source are you looking at here?
>
>
> Subject changed...
>
> The clients were as follows:
> Client 0- 1 stream up
> Client 1- 12 streams up
> Client 2- 1 stream down
> Client 3- 12 streams down
>
> It looks like what I used before was Client 3’s “TCP Download Sum avg” divided by Client 2’s “TCP Download avg” from the srchost/dsthost tests. The data’s in a table here (see column “Client 3 Mean / Client 2 Mean”):
>
> https://docs.google.com/spreadsheets/d/1e06ZfHSSmecJx9sPU2s2g2GYCS18cMIhBN8PXf1jwaM/edit?usp=sharing <https://docs.google.com/spreadsheets/d/1e06ZfHSSmecJx9sPU2s2g2GYCS18cMIhBN8PXf1jwaM/edit?usp=sharing>
>
> I was calculating by hand before, so the numbers are slightly different, but that’s the idea.
>
> Now, these tests were done at 500Mbit between two cabled APU2s, so we
> could just be running out of CPU on this hardware at lower RTTs. There
> are CPU stats included, and a “Flent Data Files” section. Is it
> possible to tell from this if CPU is the problem? The highest median
> client load I see looks to be 0.77 for the 40ms tests, for example,
> with a mean of 0.63.

Well, the CPU usage meter is just summing that first line of /proc/stat;
so yeah, individual CPUs can definitely be 100% loaded. And the fact
that the test only achieves a total of ~200 Mbps rather than the 500
would indicate that this is the case...

-Toke

  reply	other threads:[~2018-04-17  8:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20180416.110000.1863692416063182988.davem@davemloft.net>
2018-04-16 15:01 ` [Cake] Fwd: net-next is OPEN Dave Taht
2018-04-16 15:12   ` Toke Høiland-Jørgensen
2018-04-16 20:55     ` [Cake] " Pete Heist
2018-04-16 21:23       ` Toke Høiland-Jørgensen
2018-04-17  2:45         ` [Cake] fairness vs RTT Pete Heist
2018-04-17  8:24           ` Toke Høiland-Jørgensen [this message]
2018-04-17 13:52       ` [Cake] net-next is OPEN Jonathan Morton
2018-04-18  5:43         ` Pete Heist
2018-04-19 21:17           ` Pete Heist
2018-04-20  9:32             ` Toke Høiland-Jørgensen

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=871sfe5jg3.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=cake@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    --cc=pete@eventide.io \
    /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