From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 3A58F202102 for ; Sun, 12 Jan 2014 16:10:30 -0800 (PST) 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 s0D0AHAU018284; Sun, 12 Jan 2014 16:10:22 -0800 Date: Sun, 12 Jan 2014 16:10:17 -0800 (PST) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Sebastian Moeller In-Reply-To: <9EA0DCA1-79CF-48EF-9864-A51807F331B5@gmx.de> Message-ID: References: <3BF82F93-07EC-44F8-AF98-2FD156A9A43F@gmail.com> <9EA0DCA1-79CF-48EF-9864-A51807F331B5@gmx.de> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cerowrt-devel Subject: Re: [Cerowrt-devel] Perfection vs. Good Enough X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 00:10:37 -0000 On Sat, 11 Jan 2014, Sebastian Moeller wrote: >>> Compared to the orders of magnitude we already get from fq codel, the sum benefit >>> of these [Link Layer Adaptation] fixes is in the very small percentage points. > > I do not agree with this sentiment, as I understood Dave was talking > about different modifications to fq_codel (nfq_codel and efq_codel), this was > not about the link layer; for an ATM link if you get the link layer wrong the > shaper does at best work stochastically; and if the shaper does not work well > we are back at square one: badly managed buffers out of our control filling up > causing delays worth seconds. So unless you shape down to ~50% of link rate, > you will get at least temporary buffer bloat on an ATM link, unless you take > all the ATM peculiarities into account (basically what link layer ATM is > doing). the question boils down to compared to stock firmware, how much of a beneifit is openwrt trunk (and how risky) how much of a benefit is cerowrt without the link-level tuning how much additional benefit do we expect to get from the added work. What we have now is a huge step forward compared to stock firmware, a significant portion of this benefit has been pushed upstream to openwrt. but right now there is a lot of work to make things perfect, and as a result, people are stuck using stock firmware or openwrt releases (unless they compile their own image from trunk), and so they are missing everything that's been done. There is a lot of value in getting another release out that brings all the gains that we have now to everyone. Then development can continue trying to optimize things more. David Lang