[Cerowrt-devel] more steps forward

[Cerowrt-devel] more steps forward

[Dave Taht]

-1) we are working on modernizing, replicating and securing key bits of 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,
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 now
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äht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] more steps forward

[Sebastian Moeller]

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 bits of 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 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 simply, 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
> 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 now
> 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äht
> 
> 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

Re: [Cerowrt-devel] more steps forward

[Sebastian Moeller]

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… 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 <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 bits of 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 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 simply, 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
>> 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 now
>> 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äht
>> 
>> 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
> 

Re: [Cerowrt-devel] more steps forward

[Aaron Wood]

[-- Attachment #1: Type: text/plain, Size: 6435 bytes --]

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 <moeller0@gmx.de> 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. Note
> "tc -s qdisc" should allow you to see the values 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 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 <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 bits of
> 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 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 simply, 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
> >> 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 now
> >> 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äht
> >>
> >> 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
>

[-- Attachment #2: Type: text/html, Size: 8369 bytes --]