From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C3FEB3B2A4 for ; Tue, 17 Apr 2018 04:24:46 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1523953485; bh=xx9dlZDLzo+hVMQIZoD37RlwGZbo1ACe7EcA3Mu/5Yg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=UXI+IlCM2pVFw+r7HjacdrjOUCiif9TYweveNvLL7/v1Yr+U2TeAn9KQ4LUWRbb9V SDCwbMQog0jXoFKCOStuVU+hSFwaSSRMcX/1tUB/GqpGK3Gpxuq+RL+U6AC8In8f+w KCorr2T5PzqhK669i9wBMIabZmfzxS+y3fFOPOThn90GsDBCfTpV+RwPC2A791HPll 0OEfzZO+QRYXnREoLDJP5CS2WhCrsbk1Yu5SJ9aZ/Zm7BYQzE7hjugO2PWtdW9FLOc 2eB4XIfMyMNwpcWSPZT7kHXDw2up2ZIoWLdc9vMsNn9A6n9/+vQlFlii0uT+l8kfJF 5xekjl/+vSkuQ== To: Pete Heist Cc: Dave Taht , Cake List In-Reply-To: <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> <340857DC-FAA7-411B-ABDE-DEC3FC6238D9@eventide.io> Date: Tue, 17 Apr 2018 10:24:44 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <871sfe5jg3.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 08:24:47 -0000 Pete Heist writes: >> 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 tha= t 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 Down= load Sum avg=E2=80=9D divided by Client 2=E2=80=99s =E2=80=9CTCP Download a= vg=E2=80=9D from the srchost/dsthost tests. The data=E2=80=99s in a table h= ere (see column =E2=80=9CClient 3 Mean / Client 2 Mean=E2=80=9D): > > https://docs.google.com/spreadsheets/d/1e06ZfHSSmecJx9sPU2s2g2GYCS18cMIhB= N8PXf1jwaM/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. 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