From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (lang.hm [66.167.227.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 2EB153B29E for ; Mon, 4 Jun 2018 19:01:12 -0400 (EDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id w54N0oio017247; Mon, 4 Jun 2018 16:00:50 -0700 Date: Mon, 4 Jun 2018 16:00:50 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: "Bless, Roland (TM)" cc: Jan Ceuleers , bloat In-Reply-To: <73c25a21-0ace-b5ee-090e-d06fb3b8dc60@kit.edu> Message-ID: References: <152717340941.28154.812883711295847116.malone@soybean.canonical.com> <4f67f9b3-05a1-8d15-0aee-dfe8ea730d7c@gmail.com> <73c25a21-0ace-b5ee-090e-d06fb3b8dc60@kit.edu> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Mon, 04 Jun 2018 23:01:12 -0000 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. David Lang