[Cerowrt-devel] [OpenWrt-Devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt

[Dave Taht]

On Thu, Oct 09, 2014 at 01:01:48AM +0200, Stephan Günther wrote:
> Hi,
> 
> On Wed, Oct 8, 2014 at 10:10 PM, Hannu Nyman <hannu.nyman at iki.fi> wrote:
> > Dave Taht wrote on Thu Oct 2 03:49:15 CEST 2014:
> >> So I don't know where to go. Certainly I'd like to see the battle hardened
> >> sqm scripts (which are more flexible than the C code above) get more widely
> >> used and in BB.
> >
> > SQM seems to work ok with the current Chaos Calmer trunk.
> 
> Works for mee too, and performs much better than the old luci-app-qos.
> I would love to see this as part of OpenWrt.

OK. I don't see it feasible to retire qos-scripts as that has less dependencies
than sqm does - sqm needs "ip" and tc to function.

But I'd certainly like to see it available in the main openwrt repo by default.

And: I'd like the next version to do what sqm does, in pure c,
at line rate OR software rate limited, faster, better,
smaller... 
 
> I did some RRUL test using netperf-wrapper on my ADSL 15/1Mbps PPPoE
> link and it looks good in the graphs. I also have an 6in4 tunnel

I always love it when people post their results and the .json.gz files
for the various netperf-wrapper tests somewhere. It has been good to 
build an ever increasing database of valid tests and valid setups, given
that things like speedtest.net are so lame.

Examples:

http://burntchrome.blogspot.com/2014_05_01_archive.html

http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html

While I'm at it there were a couple manefestos along the way.

This explains exactly where and why wondershaper was flawed:

http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die

And this talks to the need for fq + aqm on *everything*

http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/

(I was unhappy qos-scripts just disabled ecn entirely. ECN is looking
 safely deployable in a fq'd system IMHO).

Last manefesto above does not go into the (slight) remaining need for a few levels
of classification, one reason is here:

http://perso.telecom-paristech.fr/~drossi/paper/rossi13tma-b.pdf

It is my hope that by explaining the "why" of sqm we could 
come up with something better before making it available
at larger scale.

> inside PPPoE and IIRC fq_codel should detect these ipv6 flows. RRUL

fq_codel dissects the headers for ipip, ipv6, gre and another protocol
I forget, correctly, and fq's them correctly. 

However my head explodes as to what happens or which
device should be used when that is further encapsulated.

> looks good at IPv6. Had this running at home for some days now, with
> moderate traffic and no issues so far.

Well loading it up is the only way to tell if you're winning.

> But I was wondering which interface to select luci-app-sqm, as no
> tunnel intefaces are shown here. So i used the ethernet interface
> instead of the PPPoE link. Is this fine? Minutes ago, I did a quick
> test and applied SQM to the PPPoE link by fixing luci-base to return
> also the virtual interfaces in net:get_interfaces(). But i didn't
> notice any difference or my test was too sloppy.

Well, sebastian just made a few SQM changes also in the ceropackages
repo and PPPoe over atm makes my head hurt. See cerowrt-devel
for more list. 

I'm a huge believer in measurements, and netperf-wrapper has been
the closest thing the Internet has ever had to one that accurately
measures latency under load. Recently it was proven to scale all
the way to 40GigE. 

Things like speedtest are increasingly inaccurate above 20mbits,
and doesn't measure induced latency at all...

and netalyzer, being written in java, doesn't get past 20mbits
either.

> 
> --
> Stephan
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel