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 ED1773B2A4 for ; Tue, 24 Apr 2018 05:44:39 -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=1524563078; bh=ATtHuEEP6xJ30p0q2itD2wQ/ua3alEV8zfp6YSByIjM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZSKFgM+mMUMhgp0vn0GPAQieuoADzTQqyVmOg+tqafcqz+deMc4Nzx7LhdSigdSkZ vJRc+2TtjRFhjxpgmdiNqWLGKUxRiDQcIRzF0I7Kk9QUvqMrG8r+nj9Zrk4Al1UhoI aY8s3YGBUI/i48sQ+qNr5mTWvwRFwSdRQMbVvWWO9DBmgC8D52ckyATQS1H0EELhjS YptpzJxF9gddSMZYcFFa3Ngd0YUZYGrhGbiV2rL09N6HHNDPQF+WvKKZ4onFtODmku KJyl7LpqPrxn60gL+apT6chz8TBLcLOw24HBOdQvxteq6A1LLCujgsiYrLrrbXHN2+ oZtfxF0KkecTw== To: Sebastian Moeller Cc: Pete Heist , cake@lists.bufferbloat.net In-Reply-To: <4889B2A7-331E-4513-A985-120B21876B8E@gmx.de> References: <871sf6xqne.fsf@toke.dk> <0E96CBE1-B3B8-4E2A-BB09-1EEDD4E390BF@gmx.de> <87o9i97zyh.fsf@toke.dk> <2924DAE1-7967-4D57-A4C9-67FA0ABA33E2@gmx.de> <87d0yp7xyn.fsf@toke.dk> <4889B2A7-331E-4513-A985-120B21876B8E@gmx.de> Date: Tue, 24 Apr 2018 11:44:38 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87a7tt7xbt.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Cake] Pre-print of Cake paper available 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, 24 Apr 2018 09:44:40 -0000 Sebastian Moeller writes: >> Looking at those threads, they seem to be increasing the number of >> queues. Not sure they need to, but, well, there's nothing in principle >> that says this couldn't be configurable (it is in FQ-CoDel). It would >> need a bit of a reorg of the current code, though, so that would be a >> thing for later I guess... > > I had hoped that orangetek could be convinced to do measurements > with different number of queues to answer that question, but I > guess the current default of 1000 queues is decent for a typical > homenet, but will simply become a bit tight with 600 concurrent > households (I assume that its the peak usage that would want > more queues on the "back-haul", on average 1000 might still be > okay, especially with Jonathan's clever set associativity > design) Well, there's https://www.researchgate.net/profile/S_Oueslati/publication/247045479_On_the_Scalability_of_Fair_Queueing/links/5451fab10cf285a067c6af0a/On-the-Scalability-of-Fair-Queueing.pdf -Toke