From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id CF7E53B2A4 for ; Mon, 16 Apr 2018 22:45:52 -0400 (EDT) Received: by mail-wr0-x22d.google.com with SMTP id o15so131786wro.11 for ; Mon, 16 Apr 2018 19:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eventide.io; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=cuMcOAaBnWaIHBqQtvjMaAA0hQwInvq7dGbntGagSVU=; b=MWN8N3ctXOUDL0fTdFrI7/QNzneIzQqLwD/1n5RQRRlItOOz98ym8XAvWIIwn/pdGM Ekn4rcyo1AeX6Ff8KvBDNf7dsP0LYvhabxBLkZwF6J1c5EPK5DAmurFeBO/rxkn0FOvf gp2EKVoaNCm9/wUWnScwSXRk/yZGWd2a+vx2tbZ18qE2PH0s9Ea/eLgAg9SXNOgdLZB7 9DkOkrtea5buEbWLBl9+OD1tTTT38qOTp9MAwusRSb8fgK0Knz9yHUw/0PynbbWwfIN5 gqYmnyeXbeA8GcSy0uM3JnGL+BVV374rO25DiL/fBUTihsL88LJgbQ4DAsZlBxdXoFVA pNUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=cuMcOAaBnWaIHBqQtvjMaAA0hQwInvq7dGbntGagSVU=; b=EcnaAH8s6umHJLDaYDb0WIgDagJFHIIsFzs51qyHjl0l13lxVg7Kk3ZReBmApdRsWZ cBWVN2tZehs8ihUh0G6LkOFZumCUaFEjzoWZp0CdEWN8akg3wZ941zD3f6lU6ESZykD3 pzpu4iT4RaDu7F4Eb4t79Jyyv+yTHflK2ukRBVEBtwS/99+PL3ND1S1V5K/MvW6OqHFb TY9qjV3CiQtOWPRiVlFvxvUeZjCQA9FXlZC7I5Qp8mrHDIZVrESxxHF144NxIyVQB6Fa zogprZehqAGVPKVWU5fYAZ+luiPiprYOsWcqWjfp9WJ0wnrkgZpyJXIdOBB1q41OBvvv R6Fg== X-Gm-Message-State: ALQs6tD5mdJcsuX/MTNNI0CuII9Fzfv+O5Uv6KAFuV8x7kpOSE5PsRA8 azzGpWR4we53PoAQZacnioAvyg== X-Google-Smtp-Source: AIpwx4+iX4UB3ifSFjrwMMokSE2SmvhCh2zLOX50QqhAOustbch+B/0rQEGc3IOc3VTEkE89wVwMIA== X-Received: by 10.223.163.221 with SMTP id m29mr182554wrb.4.1523933150940; Mon, 16 Apr 2018 19:45:50 -0700 (PDT) Received: from tron.luk.eventide.io (h-1169.lbcfree.net. [185.193.85.130]) by smtp.gmail.com with ESMTPSA id k30sm7980355wrf.1.2018.04.16.19.45.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 16 Apr 2018 19:45:50 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_90615BDF-740A-4036-B638-DB2531460D02" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Pete Heist In-Reply-To: <87wox64zi7.fsf@toke.dk> Date: Tue, 17 Apr 2018 04:45:49 +0200 Cc: Dave Taht , Cake List Message-Id: <340857DC-FAA7-411B-ABDE-DEC3FC6238D9@eventide.io> References: <20180416.110000.1863692416063182988.davem@davemloft.net> <87efjf5gne.fsf@toke.dk> <612F0368-751A-4127-B1F4-139FF5C3D315@eventide.io> <87wox64zi7.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3124) Subject: Re: [Cake] fairness vs RTT X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 02:45:53 -0000 --Apple-Mail=_90615BDF-740A-4036-B638-DB2531460D02 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 16, 2018, at 11:23 PM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 >> I remember that fairness behavior at low RTTs (< 20ms) needed to be >> either improved or documented, and don=E2=80=99t 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}= >> = : >>=20 >> RTT: fairness (1.0 =3D=3D 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 >=20 > 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=E2=80=99s =E2=80=9CTCP = Download Sum avg=E2=80=9D divided by Client 2=E2=80=99s =E2=80=9CTCP = Download avg=E2=80=9D from the srchost/dsthost tests. The data=E2=80=99s = in a table here (see column =E2=80=9CClient 3 Mean / Client 2 Mean=E2=80=9D= ): = https://docs.google.com/spreadsheets/d/1e06ZfHSSmecJx9sPU2s2g2GYCS18cMIhBN= 8PXf1jwaM/edit?usp=3Dsharing = I was calculating by hand before, so the numbers are slightly different, = but that=E2=80=99s 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 =E2=80=9CFlent Data Files=E2=80=9D = 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. = http://www.drhleny.cz/bufferbloat/cake/round2/hostiso_cake_100us_eg_cakeet= h_src_cakeeth_dst_500mbit/index.html = = http://www.drhleny.cz/bufferbloat/cake/round2/hostiso_cake_40ms_eg_cakeeth= _src_cakeeth_dst_500mbit/index.html = If we=E2=80=99re not sure, the tests would have to be redone at a lower = bitrate. It would probably be best if someone reproduced these results = externally anyway, and perhaps it would also be better to not be mixing = upload and download tests at the same time=E2=80=A6 :) --Apple-Mail=_90615BDF-740A-4036-B638-DB2531460D02 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 16, 2018, at 11:23 PM, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> = wrote:

I remember that fairness behavior at low RTTs = (< 20ms) needed to be
either improved or documented, = and don=E2=80=99t 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_{rt= t}_{qos-id}
<http://www.drhleny.cz/bufferbloat/cake/round2/#hostiso_cake= _%7Brtt%7D_%7Bqos-id%7D>:

RTT: fairness = (1.0 =3D=3D 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=E2=80=99s =E2=80=9CTCP = Download Sum avg=E2=80=9D divided by Client 2=E2=80=99s =E2=80=9CTCP = Download avg=E2=80=9D from the srchost/dsthost tests. The data=E2=80=99s = in a table here (see column =E2=80=9CClient 3 Mean / Client 2 = Mean=E2=80=9D):

https://docs.google.com/spreadsheets/d/1e06ZfHSSmecJx9sPU2s2g2G= YCS18cMIhBN8PXf1jwaM/edit?usp=3Dsharing

I was calculating by hand before, so = the numbers are slightly different, but that=E2=80=99s 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 =E2=80=9CFlent Data Files=E2=80=9D 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.

http://www.drhleny.cz/bufferbloat/cake/round2/hostiso_cake_100u= s_eg_cakeeth_src_cakeeth_dst_500mbit/index.html

http://www.drhleny.cz/bufferbloat/cake/round2/hostiso_cake_40ms= _eg_cakeeth_src_cakeeth_dst_500mbit/index.html

If we=E2=80=99re not = sure, the tests would have to be redone at a lower bitrate. It would = probably be best if someone reproduced these results externally anyway, = and perhaps it would also be better to not be mixing upload and download = tests at the same time=E2=80=A6 :)

= --Apple-Mail=_90615BDF-740A-4036-B638-DB2531460D02--