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 298063CB44 for ; Fri, 20 Apr 2018 05:32:57 -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=1524216775; bh=CwbcSSkGu1G6+8hNhYzfKV3+YTBh5ZixIEZfFQ+CjRs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bfwkLj/mvuWV6vVRG4iVl5pKGLFc6G1fapeqwdAVedv5j9a55EjsqyGlW/v1sQglZ Oz8QQiHVdC8FqkA1ERNDslVoUo85fQ0Eo+k3mTXrNpFHV7tTxKQOLxe62Z3XDHHtWO kMTUTzp/FYiJjQ8t3gPhRPS7o2BI2yVMYuUR5l6DVm2QCgQcryW0YLyQVcKUM6n0r1 7gUoQHl6Qaj8vhrGJDip+7fq5ShTTQaiyXbKEJAhLcfyk0HO1GtcL0F18exBZT4acC ZTb8Y3tH3TCoqkeEM7MHHf0cO/wqAH2n2MJ6nScM/VBjgbrXKxGj8GlO2aFUyJWZ0L p7oIlNcclVDFg== To: Pete Heist , Jonathan Morton Cc: Cake List In-Reply-To: <6D78919D-C4F0-4EC6-A9D4-BA81EEAC334D@eventide.io> References: <20180416.110000.1863692416063182988.davem@davemloft.net> <87efjf5gne.fsf@toke.dk> <612F0368-751A-4127-B1F4-139FF5C3D315@eventide.io> <0B624E0E-BF6C-4201-B20A-F6B77740B225@gmail.com> <129AF371-272F-4462-9EAF-71C861164E4C@eventide.io> <6D78919D-C4F0-4EC6-A9D4-BA81EEAC334D@eventide.io> Date: Fri, 20 Apr 2018 11:32:55 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87zi1yxlx4.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] net-next is OPEN... 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: Fri, 20 Apr 2018 09:32:57 -0000 Pete Heist writes: >> On Apr 18, 2018, at 7:43 AM, Pete Heist wrote: >>=20 >> I also think I saw this happen at lower bandwidths as well, when the CPU= wasn=E2=80=99t loaded. What I=E2=80=99ll do is re-test on the current vers= ion I have at, say, 50Mbit (or to where load drops substantially), then upd= ate to the head and test again, and let you know... >>=20 >>> On Apr 17, 2018, at 3:52 PM, Jonathan Morton wr= ote: >>>=20 >>>> On 16 Apr, 2018, at 11:55 pm, Pete Heist wrote: >>>>=20 >>>> I remember that fairness behavior at low RTTs (< 20ms) needed to be ei= ther improved or documented >>>=20 >>> The reason for the behaviour, IIRC, was that throughput dropped below 1= 00% when the latency target was reduced too much. Since then there has bee= n a small change which might improve it a little, so a retest would be reas= onable. > > At 50mbit I don=E2=80=99t see nearly as much fairness degradation at low = RTTs, although there=E2=80=99s some. Even at 100us, =E2=80=9Cfairness=E2=80= =9D is around 1.1 (1.0 being perfectly fair) instead of the 2.x I saw at 50= 0mbit. I do not see much of a difference between the latest code (16d7fed, = 2018-04-17) and the previous code I tested (7061401, 2017-12-01), if that i= nfo is of use. > > RTT: tcp_1up upload Mbps / tcp_12up upload Mbps > > 7061401 (2017-12-01): > > 100us: 23.80 / 25.85 > 1ms: 23.89 / 29.46 > 10ms: 23.93 / 24.66 > 40ms: 23.96 / 24.10 > 100ms: 23.97 / 24.12 > > 16d7fed (2018-04-17): > > 100us: 23.97 / 26.49 > 1ms: 23.89 / 26.27 > 10ms: 23.98 / 26.37 > 40ms: 23.94 / 24.08 > 100ms: 23.97 / 24.12 > > I can post reports / flent files on request. > > So it appears this is CPU related, and not worth exploring further(?) > and not worth documenting(?) other than that once things have > stabilized, documenting how Cake degrades under various extreme > conditions would be informative. Awesome, thanks for re-testing! :) -Toke