From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (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 2592E21F100 for ; Sat, 22 Feb 2014 05:11:08 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id wn1so297693obc.14 for ; Sat, 22 Feb 2014 05:11:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fydUuj0NCQPIme6B9+4v1DhYchX+KNQtY54kg5cka4Y=; b=R83V9STw0Ph5Qh0rnf5Gyi/UeEP5OzOXUtRZj5P4N/D10IpdKwZSQa9yBTejFAO9vL tTcEk8hsttms+NYBaRlohh3BzORVTlNXFo98cfsTLiCrBAOlGaKyxWALmcD9h3U6xlEW pA6ay6sDgEKN7kpPQY8q4s1mk6zxWBimeeI53DLiGBlbpzJpFxS2lsfd41nLlISxEb1U AGsfA6lfm1wFHmfitmxyNhRSru05nQ/yZbEuBoEHs6wQNqFo04KGJB7DDzdFGMgfJWCV jMxxUWOuJADSsN92zrozTba6JYDF/WebMkbcWUj8U0jfXUkXszXeHgIsF+OAEqcMv+zo xOJQ== MIME-Version: 1.0 X-Received: by 10.60.37.99 with SMTP id x3mr14372403oej.61.1393074666830; Sat, 22 Feb 2014 05:11:06 -0800 (PST) Received: by 10.182.92.202 with HTTP; Sat, 22 Feb 2014 05:11:06 -0800 (PST) In-Reply-To: References: <36B2FCD7-8445-4E0C-A55C-AA7AF03FDF38@gmx.de> Date: Sat, 22 Feb 2014 14:11:06 +0100 Message-ID: From: Aaron Wood To: Sebastian Moeller Content-Type: multipart/alternative; boundary=089e01176279a97f8904f2fe7898 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: Sat, 22 Feb 2014 13:11:08 -0000 --089e01176279a97f8904f2fe7898 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Let me know when this is in a build, and I'll test it here. -Aaron On Sat, Feb 22, 2014 at 12:55 AM, Sebastian Moeller wrote= : > 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. Not= e > "tc -s qdisc" should allow you to see the values that actually reached th= e > qdisc, quite helpful during testing... 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" checkb= ox. > > Best Regards > Sebastian > > > > > On Feb 17, 2014, at 22:52 , Sebastian Moeller wrote: > > > HI Dave, > > > > On Feb 17, 2014, at 20:36 , Dave Taht wrote: > > > >> -1) we are working on modernizing, replicating and securing key bits o= f > the > >> bufferbloat.net infrastructure. > >> > >> 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, > > > > 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 defau= lt > or "auto" to do the free scaling) > > > > But my most urgent point is making it possible to actually disable SQM > after enabling it :) > > > > Also of medium importance would be mutual exclusivity with regards to > openwrt QOS, the user should only be able to activate one of them... (Not= e > 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 her= e) > > > > 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... > > > > best regards > > Sebastian > > > >> 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. > >> > >> 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. > >> > >> Along with that, rename ceropackages-3.3 to ceropackages-3.10. > >> > >> And retire cerowrt-next entirely. I don't really care much about the > >> history lost here, > >> I do care about having a clean patchset. > >> > >> (this is assuming Barrier Breaker, when frozen in the next quarter or > two > >> stays on 3.10 for the ar71xx architecture.) > >> > >> This will become a longer term stable release for us. > >> > >> 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. > >> > >> I hope to get most of that out to openwrt-devel this week. > >> > >> 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. > >> > >> I MIGHT get something stable enough to use as a test box > >> after I finish item 1. > >> > >> 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 n= ow > >> I can't even look at the instruction trap problem without crashing the > >> router, so... > >> > >> 4) Got mosh working today for the first time. It's a cheap hack. > >> > >> 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. > >> > >> 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. > >> > >> This is the post-avahi, (probable) post-ahcp future, and it's got lots > >> of rough edges as yet. > >> > >> building it as modules now. > >> > >> > >> 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. > >> > >> 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. > >> > >> 7) Still would like to move babeld to run out of procd > >> > >> 8) The remainder of the backlog... > >> > >> -- > >> Dave T=E4ht > >> > >> 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 > > > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > --089e01176279a97f8904f2fe7898 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Let me know when this is in a build, and I'll test it = here.

-Aaron

<= br>
On Sat, Feb 22, 2014 at 12:55 AM, Sebastian M= oeller <moeller0@gmx.de> wrote:
Hi Dave,

so I reshuffled my todo list a bit and finished the exposure of limit and t= arget in the GUI. For target, the string auto will use the curve you recent= ly recommended for low bandwidth connections. The scripts will also increas= e 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 lim= it target to a sane upper bound (let's face it even cerowrt with all it= s 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 valu= es that actually reached the qdisc, quite helpful during testing… I = wanted to get this done so these changes can make it into the next build an= d 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 th= e "enable" checkbox.

Best Regards
        = Sebastian




On Feb 17, 2014, at 22:52 , Sebastian Moeller <moeller0@gmx.de> wrote:

> HI Dave,
>
> On Feb 17, 2014, at 20:36 , Dave Taht <dave.taht@gmail.com> wrote:
>
>> -1) we are working on modernizing, replicating and securing key bi= ts of the
>> bufferbloat.n= et infrastructure.
>>
>> 0) I would like to push the sqm scripts and gui up to openwrt-deve= l
>> for review soon. It's still missing some things I'd like -= inbound
>> diffserv to BE squashing,
>> support for dynamically setting the target,
>
>       Setting the target is still on my todo list; as y= ou 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 + (-5= ms + new_target)), so that even for long targets we have some interval to a= verage over? Anybody with a better idea, please chime in. (My plan is to al= low the user to specify a target ala "12ms" or leave it empty for= default or "auto" to do the free scaling)
>
> But my most urgent point is making it possible to actually disable SQM= after enabling it :)
>
> Also of medium importance would be mutual exclusivity with regards to = openwrt QOS, the user should only be able to activate one of them… (= Note that the openwrt recommendation for he existing 3 qos systems is simpl= y, do not run/enable them concurrently, so doing nothing might be an option= here)
>
> 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…
>
> best regards
>       Sebastian
>
>> 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.
>>
>> 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<= br> >> cerowrt-3.10 on github.
>>
>> Along with that, rename ceropackages-3.3 to ceropackages-3.10.
>>
>> And retire cerowrt-next entirely. I don't really care much abo= ut the
>> history lost here,
>> I do care about having a clean patchset.
>>
>> (this is assuming Barrier Breaker, when frozen in the next quarter= or two
>> stays on 3.10 for the ar71xx architecture.)
>>
>> This will become a longer term stable release for us.
>>
>> Most of that work is done, I'm still sorting through the patch= sets on
>> a couple fronts however, to cut them from, like dozens, to only a = few
>> that make coherent sense.
>>
>> I hope to get most of that out to openwrt-devel this week.
>>
>> 2) In terms of a shorter term stable release for us, it's evid= ent that
>> it isn't going to be this month. My cup runneth over.
>>
>> I MIGHT get something stable enough to use as a test box
>> after I finish item 1.
>>
>> 3) In sorting through the patchset I found a tiny patch that didn&= #39;t
>> make it upstream that is probably responsible for 90% of the new >> instruction traps. Not responsible for the older new ones, but rig= ht now
>> I can't even look at the instruction trap problem without cras= hing the
>> router, so...
>>
>> 4) Got mosh working today for the first time. It's a cheap hac= k.
>>
>> 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 everywh= ere to
>> survive that.
>>
>> 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.
>>
>> This is the post-avahi, (probable) post-ahcp future, and it's = got lots
>> of rough edges as yet.
>>
>> building it as modules now.
>>
>>
>> 6) I have *some* bcp38 code that works, and some ideas as to how t= o make it
>> "just work" *mostly* and be on by default, but it lacks = uci and gui integration.
>>
>> Given the marked increase in spoofed udp attacks like the recent n= tp exploit,
>> I'd like to get something that works "out there", bu= t it's clearly a
>> separate project
>> that I'd like someone else to "own" and integrate. >>
>> 7) Still would like to move babeld to run out of procd
>>
>> 8) The remainder of the backlog...
>>
>> --
>> Dave T=E4ht
>>
>> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt= /subscribe.html
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-dev= el@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >

_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.= bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

--089e01176279a97f8904f2fe7898--