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 215CE21F1A9 for ; Sun, 15 Dec 2013 15:45:03 -0800 (PST) Received: from hms-beagle-3.home.lan ([87.150.22.181]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LoVBq-1VKu9e35uE-00gU5T for ; Mon, 16 Dec 2013 00:45:00 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: Date: Mon, 16 Dec 2013 00:45:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1B2062B3-F63A-4DA7-B96E-A1A0BE9397F9@gmx.de> References: To: Dave Taht X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:xAuAWXoW8+5p0GZRHLbYrXvDidaDMErC+E6YragjYGRiwMi+lgo XNM6KIz2qJaYOa52jlIOlJZ0c6/vWMht0ucz/rLNBf1ZeH1ZMmbdUJcfvdPG3Ugg90qRFTO aoDehUYv9bu4Z2+JOrplak66mLE9uATZ10Kk20K7UC8UmspO8UvpcTnAor93CyM5JTZxb2T cctLXRUHxiqHn9qinLYDQ== Cc: "cerowrt-devel@lists.bufferbloat.net" , Jesper Dangaard Brouer Subject: Re: [Cerowrt-devel] aqm gui feedback on cerowrt-3.10.24-1 for linklayer adaption 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: Sun, 15 Dec 2013 23:45:03 -0000 hI Dave hi list, On Dec 14, 2013, at 07:26 , Dave Taht wrote: > one of the things that makes me happy with all-up testing is that > occasionally after completely blowing up my own work, I get to > critique fresh work that isn't mine, in an area with which I have no > expertise, with gratitude that I don't have to figure out the answer. > :) >=20 > So I spent some time clicking wildly all over the AQM gui webpage to > see what I could break. >=20 > 1) the aqm gui code doesn't work due to a bug at line 66. > sc:depends("advanced", "1"). > sc has to be initialized first, which happens later in the file. Extra > line removed in ceropackages, committed, pushed, you will need to do a > pull. Merge failure? >=20 > 2) it's not clear to me we have to support both the stab and > htb_private methods of fixing htb's linklayer. It was important that > these be fixed for everyone else that uses htb, > but is one of these is faster than the other? I seem to recall one was > a calculated value in the kernel, the other some sort of table. Does > this choice need to be made by the > user? The two variants benchmarked? Jesper? So I just went ahead and hid htb_private for the time being (by = commenting out the definition in aqm.lua, can=20 only be reenabled by editing, this is not ideal, but at lease confusing = than the situation before) >=20 > 3) Clicking "advanced configuration" on and off toggles display of the > qdisc and qdisc script, and twiddling with the linklayer value brings > up all the extra DSL detail. Yea! >=20 > ... and I think I was wrong in mentally visualizing the thing >=20 > If these were made tabs [Basic, Queueing Discipline, Linklayer, > Priorities], there would be more room for explanatory text in > particular and better alignment with the > "look and feel" of the rest of the gui. Note that "priorities" is a > placeholder for somehow > bringing out something remotely similar to what openwrt's qos system > already does > and what AQM (ceroshaper? some other name is needed) does implicitly > with optimizing for dns and ntp. The tabs are in. Since "Priorities" would be empty it does not = exist yet. Let's see how you like the rest... >=20 > ECN enablement should be brought out in "Queueing discipline" via the > ALLECN variable. It seems likely ALLECN needs to have 4 states rather > than 3, which needs to also be fixed in the scripts. >=20 > While I'm at it, perhaps having tabs for each physical interface is > not a horrible idea, > but I shudder to think of people rate-limiting their wifi in the hope > that that would help. >=20 > ? >=20 > 5) Adding a second interface shows @ge01 as an option, which isn't a > real interface, and se00 as an option and not the gw* or sw* > interfaces. Adding se00 with the default option > gives me an error >=20 > One or more required fields have no value! > One or more required fields have no value! > One or more required fields have no value! > One or more required fields have no value! >=20 > (and I'm pretty sure the aqm-scripts break even if this is correctly > written to the config file) >=20 > 6) feel free to add your copyright to the code. :) >=20 > I return now to figuring out why bringing up the wifi is so hosed. I > will probably be reverting the kernel, netifd, and other things, way, > way, way back to when they used to work. >=20 > --=20 > Dave T=E4ht >=20 > Fixing bufferbloat with cerowrt: = http://www.teklibre.com/cerowrt/subscribe.html > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel