From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 9A29521F1D4 for ; Sun, 15 Dec 2013 06:04:45 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id e16so2967950qcx.13 for ; Sun, 15 Dec 2013 06:04:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ketpSElJyUYpFYyYcrV331Cctc5eV8qNSSYbPPJe8EA=; b=lbXBdNUhSR88IsO3VVvQc3OHzo2i1SiveDtdeoCzLkHcQSDbnJDritFiu8729YsM7A Epe2Dn2JUqaKTF4P3Cbz9KtELM1BSvERcvgdLLahmAlFftyf7ZqaX2SoO7D91oGrb7dr A06v4kS4R/tV4tPnkieESPwbg2PsyP9YFi16Sw9xxE7wlb3Hu0zsdVeNJzBvT7TDmcjI SXg3bh48qs2ZLxHaBNLyDsXG6DXPvyEHWYKm+sk4KIrdiN3kCKv9CZFvIuw2UXgl+/7C bnVNu5UnXlhYwLBFPw5HOfyTZ/ZyKqXB0fCP3+uIZI2jiHr9B1vLJlb4FzKpeF6R7IIa dT1g== X-Received: by 10.229.194.1 with SMTP id dw1mr23428636qcb.20.1387116284538; Sun, 15 Dec 2013 06:04:44 -0800 (PST) Received: from [172.30.43.25] ([64.222.214.22]) by mx.google.com with ESMTPSA id f19sm32234771qaq.12.2013.12.15.06.04.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Dec 2013 06:04:44 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Rich Brown In-Reply-To: <62C46991-29BF-40D7-8D4F-D3B2E27A87D7@gmx.de> Date: Sun, 15 Dec 2013 09:04:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <472E1EFA-1D6E-460B-AB2E-6E55D63184AD@gmail.com> <62C46991-29BF-40D7-8D4F-D3B2E27A87D7@gmx.de> To: Sebastian Moeller X-Mailer: Apple Mail (2.1822) Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] Field Report on CeroWrt 3.10.24-1/AQM GUI 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 14:04:45 -0000 Hi Sebastian, Fred, Toke, Thanks for all these comments about the AQM GUI. It feels to me that = we=92re working on an interesting (GUI) design challenge along with all = the technical wrassling that=92s going on: - Are we leaving enough knobs and levers exposed so that people can = easily help us with research into the best settings? - Are we aiming toward a set of default parameters that people can set = and forget? I suspect that the answer to both is =93yes=94, but the real question = we=92re talking about now is *when* we do each. My vote: - For now, leave more knobs and levers exposed. If we do this... - We need to provide guidance for these settings. I am not (yet) = sufficiently familiar with the issues to make these judgements/decisions = on my own.=20 - I never want to see paragraphs of text in a GUI. That simply implies = that the GUI needs to link to a page on the wiki with our collective = wisdom on the subject. I=92ll help with that. Best, Rich On Dec 15, 2013, at 6:33 AM, Sebastian Moeller wrote: > Hi Rich, >=20 >=20 > On Dec 15, 2013, at 06:16 , Rich Brown = wrote: >=20 >> I did a tftp install of CeroWrt 3.10.42-1 on my secondary WNDR3800. I = then used the =93secondary=94 script to reconfigure the subnets and = SSIDs to be different from my primary CeroWrt router. I know that a lot = of things are still in flux, but I thought I should comment that I = noticed the following: >>=20 >> 0) It seems to work mostly. I could connect my MacBook on Ethernet, = but not wireless (see below) I ran RRUL with reasonable results (I = think)=20 >>=20 >> 1) Only the ge00 interface was in its proper firewall zone (wan); I = used the GUI to move all the gwxx to guest and se00 and swxx interfaces = to lan. >>=20 >> 2) None of the wireless SSIDs (2.4 or 5 GHz) allowed connections. It = appears that they=92re there, my MacBook sees them, but it cannot get an = address for itself on those SSIDs. =20 >>=20 >> 3) Clicking the AQM tab gave the following diagnostic info: >>=20 >> /usr/lib/lua/luci/dispatcher.lua:448: Failed to execute cbi = dispatcher target for entry '/admin/network/aqm'. >> The called action terminated with an exception: >> /usr/lib/lua/luci/model/cbi/aqm.lua:63: attempt to index global 'sc' = (a nil value) >> stack traceback: >> [C]: in function 'assert' >> /usr/lib/lua/luci/dispatcher.lua:448: in function 'dispatch' >> /usr/lib/lua/luci/dispatcher.lua:195: in function = >>=20 >> 3a) To work around this (as noted in another message on the list), = remove leading =93s=94 of line 63 of /usr/lib/lua/luci/model/cbi/aqm.lua = to read: >>=20 >> c:depends("advanced", "1=94) >=20 > Sorry for that, I committed an untested change (adding two = lines, how much can go wrong?) and forgot to edit the 2nd copy... >=20 >>=20 >> 4) In the AQM tab, I=92m not sure which linklayer adaptation = mechanism to use. >=20 > If you have DSL either is good. In case you work with jumbo = packets on ge00 or use GSO you should use htb_private, otherwise both = are fine. (I will try to get patches for tc_stab into the kernel that = makes this difference moot ad might alls us to consolidate on the = generic tc_stab). I will add this information onto the GUI. (Since there = are only few users for the link layer adjustments, both methods are = somewhat prone to bitrott, so I think it has value to expose both so = that we can cross test both, assuming both will not go bad at the same = kernel revision...) >=20 >=20 >> It would be good to have a concise summary of the proper settings for = various use cases. >=20 > Well, yes it would, unfortunately it is slightly tricky to do = so. Dave proposed a redesign of the AQM GUI page with tabs for the = different functional pieces. When I prototype this I will try to include = more information about properly selecting those values. That said = typically mpu shopule be zero, tcMTU should be 2047 (as the interface = MTU will be around 1500), tsize should be 128. Overhead is the trickiest = as it depends on the actual encapsulation used on your link. If I am = correct the maximum for this is 44 and a typical value is 40, so we = could default to 44 to do no damage but we would waste bandwidth for = almost everybody. What do you think about including links in the GUI so = the user can go and read up on this? (I would recommend = http://www.faqs.org/rfcs/rfc2684.html and = http://ace-host.stuart.id.au/russell/files/tc/tc-atm/ but both are not = that easy to digest...) >=20 >> (And to install a set of defaults that will =93do the right thing=94 = for the majority of people, so we don=92t have to explain it very = often.) >=20 > Okay, realistically the most important thing is to select one of = the mechanisms to account for the link layer if you are on ATM based = DSL, so typically ADSL1, ADSL2, ADSL2+ (with an off chance with VDSL1), = assuming a typical link the link MTU will be ~1500 so the defaults for = tcMTU tsize and MPU will work fine. We could set the default link layer = to ADSL and the default overhead to 40 if Dave agrees, to preconfigure a = reasonable default=85 > I have been thinking about how to detect the link layer = quantization and the protocol overhead automatically, but so far do not = have anything useful to include with cerowrt (on a fast link one needs = to measure all night to get small enough deviations to reliably detect = the quantisation). If you are willing to play guinea pig I will send you = the measurement script... >=20 >=20 >>=20 >> 5) I did *not* try the Hurricane Electric 6in4 tunnel. >>=20 >> Best regards, >>=20 >> Rich Brown >> Hanover, NH >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >=20