[Cerowrt-devel] more steps forward

Sat Feb 22 08:11:06 EST 2014

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 at 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 at gmx.de> wrote:
>
> > HI Dave,
> >
> > On Feb 17, 2014, at 20:36 , Dave Taht <dave.taht at 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 at lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140222/f845e48c/attachment-0002.html>