From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id B205121F1A1 for ; Sat, 7 Dec 2013 03:24:21 -0800 (PST) Received: from hms-beagle-3.home.lan ([87.150.22.181]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MVui8-1W4mhm2MXo-00X6Mg for ; Sat, 07 Dec 2013 12:24:18 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: Date: Sat, 7 Dec 2013 12:24:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <13A953B7-EDAF-4767-8C9B-B05D4447D964@gmx.de> References: <20131203222559.GV8066@einstein.kenyonralph.com> <7ieh5pew2d.wl%jch@pps.univ-paris-diderot.fr> To: Dave Taht X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:gIMJrmrD7AZqX0QKH61MWWgbbNtMXbW7g/T2Yos250cVJuDWA0h pnbnZ9jhJ/zWjQa9w8G6km+l64uI00JiSaOhN3FAQF7TkcuAp3a51rUraTkzCO/jmd9Iw8V Co1cz+pRLI0VbIY+uYk4RZYwqyIlCjYN3jSkTd24Vca+NCKJN0RJKGBBHS9jIoyIGWTUjaX ECkW/XFVb1fXjVJBZYn1w== Cc: bloat , Juliusz Chroboczek Subject: Re: [Bloat] curious..... X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 11:24:22 -0000 Hi Dave, On Dec 6, 2013, at 19:15 , Dave Taht wrote: > On Fri, Dec 6, 2013 at 9:19 AM, Juliusz Chroboczek > wrote: >>> I note that openwrt's qos-scripts still do not do ipv6 properly, and = I think >>> cerowrt's aqm system is better in most respects, and it's easy to >>> include on an openwrt system. >>=20 >> Perhaps you should push your system to OpenWRT? >=20 > There is still some work going on to streamline the gui. there are > less features in the aqm-scripts for > prioritizing packet types than qos-scripts. Do you think these additional features are essential? I assume = that openwork would not immediately drop their QOS packet so "AQM/SQM" = and QOS will live together for some time, so having slightly different = features might still be okay. > I just had to come up with > a way to disable it at high (> 80 mbit) rates on incoming traffic (not > enough cpu in cerowrt), so I'd like it to run faster, maybe using drr > in that case, or something like what free.fr uses... >=20 > And there are actually two aqm/packet scheduling shapers in there (a > simple 1 tier and a 3 tier one) What is your opinion, should we default to the single tier = version or the 3 tier version? > , and it supports a variety of > aqm/scheduling algorithms, not just fq_codel, which is there for the > research but will confuse the end users=85 I guess it should be relatively easy to hide this under the = control of a "I know what I am doing give me all the knobs to play with" = checkbox with a scary name, say "research"=85 :) Question, I tried to send you a version of aqm.lua that hides = the detailed link layer fields in the GUI if none is selected as link = layer adaptation mechanism did that ever reach you (I have some issues = with my mailer so it might not have made it out of my system for good)? = But in the same vain, hiding "Queueing discipline" and "Queue setup = script" should be simple... > and I am not happy with > "aqm" at a word, because the packet scheduling part counts for a LOT, > so i'd rename it to sqm or someting like that. What about the long and verbose "Latency and Bandwidth Control" = or something else that talks about the "benefit" to the user? >=20 > So I'd argue it needs some love. And a solid set of requirements that > it meets before it is as standardized as, say, wondershaper is. And if > it got that standardized, I think it would run a heck of a lot faster > if it got poured into C. Just curious, isn't the kernel doing all the work for us? I = ,foolishly?, assumed that the script is just configuring the kernel and = since this is done rarely why would we bother about the run time... >=20 > However it is pretty stable and could definitely use more eyeballs, > and it works right with ipv6 and seems better than qos-scripts on most > benchmarks... so I'll ask the openwrt folk if they want it upstream. >=20 > In the interim, existing openwrt users can add ceropackages-3.3 into > their feeds. >=20 > And incorporate it into their build with >=20 > ./scripts feeds install aqm-scripts luci-app-aqm Note: people should at least disable openwork's QOS before = activating "AQM"; or should we teach AQM to either disable qos on = activation or at least warn the user about a potential conflict. I = assume people will want to compare the performance of both=85 best Sebastian >=20 >=20 >=20 >> -- Juliusz >=20 >=20 >=20 > --=20 > Dave T=E4ht >=20 > Fixing bufferbloat with cerowrt: = http://www.teklibre.com/cerowrt/subscribe.html > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat