Hi Dave,
On Dec 6, 2013, at 19:15 , Dave Taht <dave.t...@gmail.com> wrote:
> On Fri, Dec 6, 2013 at 9:19 AM, Juliusz Chroboczek
> <j...@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
