From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 A0E09201904 for ; Fri, 21 Feb 2014 15:56:03 -0800 (PST) Received: from hms-beagle.home.lan ([217.86.112.208]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MgcTf-1Wb0sC395L-00Nwq1 for ; Sat, 22 Feb 2014 00:55:59 +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: <36B2FCD7-8445-4E0C-A55C-AA7AF03FDF38@gmx.de> Date: Sat, 22 Feb 2014 00:55:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <36B2FCD7-8445-4E0C-A55C-AA7AF03FDF38@gmx.de> To: Dave Taht X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:LcuLrHmcxfx9A27MucTWf0RBwUl5CrKaZ8rL/ziVsGGsc1BE52q Wdc7954unZ4cnja50/vK9dVwAWlxNgPyEWmRyaT4eZyiIRtAy9CNTHMD2vFJjd5PNoQshWH XhHWGH54Ir2jqgpvDVpym5kzBGKM3tsjxVUK74np40nIoV3QXABxfmf+E9y+mCs9DXS+WQe xblYRzv8YZa53Ot8pGUAg== Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] more steps forward 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: Fri, 21 Feb 2014 23:56:04 -0000 Hi Dave, so I reshuffled my todo list a bit and finished the exposure of limit = and target in the GUI. For target, the string auto will use the curve = you recently recommended for low bandwidth connections. The scripts will = also increase interval by the same amount, so interval> target will = always be true. Target will never get smaller than 5ms and I assume that = we should also limit target to a sane upper bound (let's face it even = cerowrt with all its tricks will not turn a 300baud acoustic coupler = into a snappy sped-racer ;) ). I tried to test my changes, but I remember well that that did = not work out too well last time, so please everyone go ahead and test = it. Note "tc -s qdisc" should allow you to see the values that actually = reached the qdisc, quite helpful during testing=85 I wanted to get this = done so these changes can make it into the next build and can get a = better and more diverse testing by all the fine members of the = cerowrt-devel list ;) Next stop, is then stopping shaping and tearing down the = existing HTB hierarchy when the user disables SQM via clearing the = "enable" checkbox. Best Regards Sebastian On Feb 17, 2014, at 22:52 , Sebastian Moeller wrote: > HI Dave, >=20 > On Feb 17, 2014, at 20:36 , Dave Taht wrote: >=20 >> -1) we are working on modernizing, replicating and securing key bits = of the >> bufferbloat.net infrastructure. >>=20 >> 0) I would like to push the sqm scripts and gui up to openwrt-devel >> for review soon. It's still missing some things I'd like - inbound >> diffserv to BE squashing, >> support for dynamically setting the target, >=20 > Setting the target is still on my todo list; as you noted in the = past we will run into an issue once the target gets larger than interval = though; what about setting interval to max(100ms, 100ms + (-5ms + = new_target)), so that even for long targets we have some interval to = average over? Anybody with a better idea, please chime in. (My plan is = to allow the user to specify a target ala "12ms" or leave it empty for = default or "auto" to do the free scaling) >=20 > But my most urgent point is making it possible to actually disable SQM = after enabling it :) >=20 > Also of medium importance would be mutual exclusivity with regards to = openwrt QOS, the user should only be able to activate one of them=85 = (Note that the openwrt recommendation for he existing 3 qos systems is = simply, do not run/enable them concurrently, so doing nothing might be = an option here) >=20 > I currently am pressed for time, so I can not promise to finish any of = these three goals any time soon, but I will try=85 >=20 > best regards > Sebastian >=20 >> a drr emulation of what free.fr does, some stuff I have for emulating >> typical dsl and cable modem behavior... and any way of more easily >> doing custom prioritizations, but it is what it is, and can be >> improved with more eyeballs on it. >>=20 >> 1) I am planning to rebase the cerowrt-next tree with a cleaner >> patchset, push as much up to openwrt as possible, and put it into >> cerowrt-3.10 on github. >>=20 >> Along with that, rename ceropackages-3.3 to ceropackages-3.10. >>=20 >> And retire cerowrt-next entirely. I don't really care much about the >> history lost here, >> I do care about having a clean patchset. >>=20 >> (this is assuming Barrier Breaker, when frozen in the next quarter or = two >> stays on 3.10 for the ar71xx architecture.) >>=20 >> This will become a longer term stable release for us. >>=20 >> Most of that work is done, I'm still sorting through the patchsets on >> a couple fronts however, to cut them from, like dozens, to only a few >> that make coherent sense. >>=20 >> I hope to get most of that out to openwrt-devel this week. >>=20 >> 2) In terms of a shorter term stable release for us, it's evident = that >> it isn't going to be this month. My cup runneth over. >>=20 >> I MIGHT get something stable enough to use as a test box >> after I finish item 1. >>=20 >> 3) In sorting through the patchset I found a tiny patch that didn't >> make it upstream that is probably responsible for 90% of the new >> instruction traps. Not responsible for the older new ones, but right = now >> I can't even look at the instruction trap problem without crashing = the >> router, so... >>=20 >> 4) Got mosh working today for the first time. It's a cheap hack. >>=20 >> I don't know if anybody else cares >> but as for me, I am so frequently blowing up my network and losing >> state on a dozen boxes >> that it's a relief to be able to cut over to pure mosh everywhere to >> survive that. >>=20 >> 5) The latest mdnsresponder code landed, and the new hnetd and dns >> hybrid proxy code >> is being maintained in the homewrt group's repos, which I just added >> to cerowrt's feeds. >>=20 >> This is the post-avahi, (probable) post-ahcp future, and it's got = lots >> of rough edges as yet. >>=20 >> building it as modules now. >>=20 >>=20 >> 6) I have *some* bcp38 code that works, and some ideas as to how to = make it >> "just work" *mostly* and be on by default, but it lacks uci and gui = integration. >>=20 >> Given the marked increase in spoofed udp attacks like the recent ntp = exploit, >> I'd like to get something that works "out there", but it's clearly a >> separate project >> that I'd like someone else to "own" and integrate. >>=20 >> 7) Still would like to move babeld to run out of procd >>=20 >> 8) The remainder of the backlog... >>=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 >=20