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 A4AE53CB36 for ; Thu, 19 Apr 2018 05:26:25 -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=1524129984; bh=0US6E/JpBeLSu4ybgFL7h+gWGhxCfijG2W3dcXTrNo8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=voxCOGL2An6/U0abgmGVvgwCeNARD+nkRkPZftu+ZRSq6u8DrAXNzYaW9VK75J+eq D6IQ/Po5R7Muc9pN7cUiTX2M0VADWZEcOkPvFmzROrdZbSLzt5leGUklL4rZxvxEqW 4ZA4X9dGKwtqXDj+juGHsCte3o8mgo2sn4S3Zrx/AHbw4dOau83+Ich5pAvSey3ZJM jKbONcbSnJWpFiQh9peF25HkIudIFBBVyL1Y6brdVMJZC2WMq0G36Hf0UWGZMBCiOC JC14+KKB4KIRmhV8K5gTsvg5XcN+tUF2D4YJc++0NtE3RWbf0e2XmfUqLId7AqJkkz X2ijkmYAcR9wQ== To: Jonathan Morton Cc: Luca Muscariello , Cake List In-Reply-To: <3B813EB8-92E7-402D-8BF5-DD43971155E4@gmail.com> References: <87vacq419h.fsf@toke.dk> <874lk9533l.fsf@toke.dk> <87604o3get.fsf@toke.dk> <578552B2-5127-451A-AFE8-93AE9BB07368@gmail.com> <87r2nc1taq.fsf@toke.dk> <0BB8B1FD-6A00-49D6-806E-794BD53A449F@gmx.de> <3457DD8E-0292-4802-BD1E-B37771DCADA2@gmail.com> <87fu3s1om2.fsf@toke.dk> <87d0yv1sfz.fsf@toke.dk> <3B813EB8-92E7-402D-8BF5-DD43971155E4@gmail.com> Date: Thu, 19 Apr 2018 11:26:24 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87y3hjzgvz.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 19 Apr 2018 09:26:25 -0000 Jonathan Morton writes: >> your solution significantly hurts performance in the common case > > I'm sorry - did someone actually describe such a case? I must have > missed it. I started this whole thread by pointing out that this behaviour results in the delay of the TCP flows scaling with the number of active flows; and that for 32 active flows (on a 10Mbps link), this results in the latency being three times higher than for FQ-CoDel on the same link. This was the message: https://lists.bufferbloat.net/pipermail/cake/2018-April/003405.html And this graph, specifically: https://lists.bufferbloat.net/pipermail/cake/attachments/20180417/1e56d8f3/attachment-0002.png It's even worse for 64 flows, obviously; and there's no change in goodput. -Toke