[Cerowrt-devel] Fwd: Re: more steps forward

[Dave Taht]

On Mon, Feb 17, 2014 at 5:24 PM, Fred Stratton <fredstratton at imap.cc> wrote:

>
>
>
> -------- Original Message --------  Subject: Re: [Cerowrt-devel] more
> steps forward  Date: Mon, 17 Feb 2014 22:24:06 +0000  From: Fred Stratton
> <fredstratton at xyz.am> <fredstratton at xyz.am>  To: Sebastian Moeller
> <moeller0 at gmx.de> <moeller0 at gmx.de>, cerowrt-devel at lists.bufferbloat.net
>
> For later in the process, this has appeared:
> https://github.com/sivel/speedtest-cli
>
>
Possibly useful. 500 lines of python. Could probably rewrite in C in less.


>
>
> On 17/02/14 21:52, Sebastian Moeller wrote:
> > HI Dave,
> >
> > On Feb 17, 2014, at 20:36 , Dave Taht <dave.taht at gmail.com> <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
>
>
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>


-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140217/9354b167/attachment-0002.html>