From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 32E9B3B29E for ; Tue, 5 Jun 2018 03:44:27 -0400 (EDT) Received: from i72t450mh.tm.uni-karlsruhe.de ([141.3.71.47]) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 587 iface 141.3.10.81 id 1fQ6dm-0004dL-5E for ; Tue, 05 Jun 2018 09:44:26 +0200 To: bloat@lists.bufferbloat.net References: <152717340941.28154.812883711295847116.malone@soybean.canonical.com> <4f67f9b3-05a1-8d15-0aee-dfe8ea730d7c@gmail.com> <73c25a21-0ace-b5ee-090e-d06fb3b8dc60@kit.edu> From: Mario Hock Message-ID: Date: Tue, 5 Jun 2018 09:44:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de esmtpsa 1528184666.229813606 Subject: Re: [Bloat] Fwd: [Bug 1436945] Re: devel: consider fq_codel as the default qdisc for networking X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 07:44:27 -0000 Am 05.06.2018 um 01:00 schrieb David Lang: > On Mon, 4 Jun 2018, Bless, Roland (TM) wrote: > >> Hi, >> >> Am 24.05.2018 um 17:38 schrieb Jan Ceuleers: >>> Took 3 years after Dave approached them, but Ubuntu is finally adopting >>> fq_codel as the default qdisc. >> >> Yes, if the Linux kernel is forwarding packets it makes a lot of sense, >> but I don't understand why it make sense for ordinary end-systems. >> Didn't Byte Queue Limits (BQL) suffice? Just curious... > > no, BQL makes things much better (and make it possible for more advanced > quueing to take place), but you can still run into problems where a bulk > stream can flood the output queue so that other traffic suffers badly. > > with fq_codel, the available bandwidth is distributed in a way that ends > up being much more functional. > > It turns out that the behavior to prioritize new and sparse connections > significantly improves perceived performance (no more long delays in DNS > lookups before you start doing any real work for example) > > without BQL, you can't even see the rest of the problems, but BQL > doesn't solve everything. Just to make sure that I got your answer correctly. The benefit for endsystems comes from the "fq" (flow queuing) part, not from the "codel" part of fq_codel? Mario Hock