[Bloat] curious.....

[Sebastian Moeller]

Hi Dave,


On Dec 6, 2013, at 19:15 , Dave Taht <dave.taht at gmail.com> wrote:

> On Fri, Dec 6, 2013 at 9:19 AM, Juliusz Chroboczek
> <jch at pps.univ-paris-diderot.fr> wrote:
>>> I note that openwrt's qos-scripts still do not do ipv6 properly, and I think
>>> cerowrt's aqm system is better in most respects, and it's easy to
>>> include on an openwrt system.
>> 
>> Perhaps you should push your system to OpenWRT?
> 
> There is still some work going on to streamline the gui. there are
> less features in the aqm-scripts for
> prioritizing packet types than qos-scripts.

	Do you think these additional features are essential? I assume that openwork would not immediately drop their QOS packet so "AQM/SQM" and QOS will live together for some time, so having slightly different features might still be okay.

> I just had to come up with
> a way to disable it at high (> 80 mbit) rates on incoming traffic (not
> enough cpu in cerowrt), so I'd like it to run faster, maybe using drr
> in that case, or something like what free.fr uses...
> 
> And there are actually two aqm/packet scheduling shapers in there (a
> simple 1 tier and a 3 tier one)

	What is your opinion, should we default to the single tier version or the 3 tier version?

> , and it supports a variety of
> aqm/scheduling  algorithms, not just fq_codel, which is there for the
> research but will confuse the end users…

	I guess it should be relatively easy to hide this under the control of a "I know what I am doing give me all the knobs to play with" checkbox with a scary name, say "research"… :)
	Question, I tried to send you a version of aqm.lua that hides the detailed link layer fields in the GUI if none is selected as link layer adaptation mechanism did that ever reach you (I have some issues with my mailer so it might not have made it out of my system for good)? But in the same vain, hiding "Queueing discipline" and "Queue setup script" should be simple...

> and I am not happy with
> "aqm" at a word, because the packet scheduling part counts for a LOT,
> so i'd rename it to sqm or someting like that.

	What about the long and verbose "Latency and Bandwidth Control" or something else that talks about the "benefit" to the user?

> 
> So I'd argue it needs some love. And a solid set of requirements that
> it meets before it is as standardized as, say, wondershaper is. And if
> it got that standardized, I think it would run a heck of a lot faster
> if it got poured into C.

	Just curious, isn't the kernel doing all the work for us? I ,foolishly?, assumed that the script is just configuring the kernel and since this is done rarely why would we bother about the run time...

> 
> However it is pretty stable and could definitely use more eyeballs,
> and it works right with ipv6 and seems better than qos-scripts on most
> benchmarks... so I'll ask the openwrt folk if they want it upstream.
> 
> In the interim, existing openwrt users can add ceropackages-3.3 into
> their feeds.
> 
> And incorporate it into their build with
> 
> ./scripts feeds install aqm-scripts luci-app-aqm

	Note: people should at least disable openwork's QOS before activating "AQM"; or should we teach AQM to either disable qos on activation or at least warn the user about a potential conflict. I assume people will want to compare the performance of both…

best
	Sebastian

> 
> 
> 
>> -- Juliusz
> 
> 
> 
> -- 
> Dave Täht
> 
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat