On Mon, Feb 17, 2014 at 5:24 PM, Fred Stratton <[email protected]> wrote:
> > > > -------- Original Message -------- Subject: Re: [Cerowrt-devel] more > steps forward Date: Mon, 17 Feb 2014 22:24:06 +0000 From: Fred Stratton > <[email protected]> <[email protected]> To: Sebastian Moeller > <[email protected]> <[email protected]>, [email protected] > > 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 <[email protected]> > > <[email protected]> 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 > >> [email protected] > >> https://lists.bufferbloat.net/listinfo/cerowrt-devel > > _______________________________________________ > > Cerowrt-devel mailing list > > [email protected] > > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > > > _______________________________________________ > Cerowrt-devel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
_______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
