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. 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 wrote: > > > HI Dave, > > > > On Feb 17, 2014, at 20:36 , Dave Taht 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 >