From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 617013B29E for ; Tue, 17 Apr 2018 10:17:52 -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=1523974670; bh=YDBCToaXbappLXX9li7jBEJuKN/8WVUtkuvACB+RqUc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Fxgl1LH519Lw/H9SacT8Og5JB18TnkrQ5lZGtyxAU1aW+4lJ3217/sSxmc6sWQEaO SwAVkGJVEOpOOQmV+TKxiETd88DnN9QNXRUCsYuoaaPCzeBbJbbHvxPO41M/U9hml6 l435iwOcIJqwx45PmO2kDC1ZBcbA53iMJLNY2yNYKREVuB3glXNWB9Pls+BYgIcHxS dcaetpffxECSay7GZDKlAroFlYrtx0xQSo281kBg5DPIR9wBpR4B9i4GepTmEENbaD q5ppQMUg3A+b14hPWMZWYp6NEHLWrP7fCI9ClygOhdtn2suvuJ5O1lPVrrchqvophr Cjv+zNfbsYJOg== To: Jonathan Morton Cc: cake@lists.bufferbloat.net In-Reply-To: References: <87vacq419h.fsf@toke.dk> Date: Tue, 17 Apr 2018 16:17:50 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <874lk9533l.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] A few puzzling Cake results 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 14:17:52 -0000 Jonathan Morton writes: >> On 17 Apr, 2018, at 12:42 pm, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >> - The TCP RTT of the 32 flows is *way* higher for Cake. FQ-CoDel >> controls TCP flow latency to around 65 ms, while for Cake it is all >> the way up around the 180ms mark. Is the Codel version in Cake too >> lenient, or what is going on here? > > A recent change was to increase the target dynamically so that at > least 4 MTUs per flow could fit in each queue without AQM activity. > That should improve throughput in high-contention scenarios, but it > does come at the expense of intra-flow latency when it's relevant. Ah, right, that might explain it. In the 128 flow case each flow has less than 100 Kbps available to it, so four MTUs are going to take a while to dequeue... > To see whether Diffserv actually prioritises correctly, you'll need to > increase the number of bulk flows beyond the point where the VoIP flow > no longer receives the bandwidth it needs purely from its fair share > of the link. Yup, which is what I have been unable to do for the VoIP flow case. I guess I'll have to try with a flow that has a bit higher bandwidth... -Toke