[Cerowrt-devel] Status of SQM-Scripts integration into OpenWRT Barrier Breaker?

Mon Aug 25 17:07:27 EDT 2014

On Mon, Aug 25, 2014 at 5:53 AM, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
> "Frits Riep" <riep at riepnet.com> writes:
>
>> I may be misunderstanding, but I thought this was a goal. Am I
>> incorrect, or have the plans changed?

No the plan is and has always been to push the SQM system upstream not
just to openwrt
but also to a debian and fedora installable package.

I would have settled for improving the qos-scripts to handle ipv6
correctly, however.

> Don't think the plans have changed per se. More of a case of needing
> more testing to be included in Openwrt.

I note that the past month has been the first time in several years
that I didn't build
a version of cerowrt even weekly. The last 8 months have been
something of a "death
march" for me on getting it stable (see  bug 442, seemingly fixed in
3.10.50-1), and it has been a real relief
to put it down for a while and catch up on other things (like sleep
and paying work).

I do plan to resync with barrier breaker RC3 or RC4, but I don't mind
at all taking a few more weeks away from it to breathe and plan on the
next major phase of it all, which is to make-wifi-fast. There is also
a need to do a "bql-on-everything" project, identifying and fixing
(adding 4-8 lines of code to) all the ethernet chips found in openwrt
platforms...

...and I'd also like to clearly identify at least one openwrt board
that worked well at line rate on USA DSL.

As for SQM...

There are a couple things still missing from SQM that I would like to
have in there.

1) Detection of actually available AQM and packet scheduling kernel
modules so that the user can't choose something that is unavailable
either at the command line or the gui
2) better control of prioritization as per qos-scripts
3) debian apt, fedora rpm, and arch pacman packaging
4) A rewrite to make it smaller and cleaner

Moving further forward:

There is a feature I'd longed to have which is to have the three tier
"simplest" setup work at line rate rather than through htb. This would
probably involve writing a new qdisc entirely or switching to a DRR +
fq_codel based system more like what free.fr uses. Despite multiple
efforts we never managed to beat that...

Performance on low end hardware is a real problem, we peak out at
about 50mbits of shaping on the (processor designed in 1989!) wndr3800
we presently use, and seem to have hit a similar (if slightly higher)
limit on the edge router lite hardware. So coming up with a faster
thing than htb would be nice also, as well as some way to warn the
user they are seeking an impossible to achieve setting.

Gargoyle (and stream boost) have an automatic bandwidth sensing system
which is worth looking at.

Better onboard tests for determining a "good" rate would also be nice.
netperf, as currently used is a bit heavyweight, and although we have
ramped up to a half dozen donated end servers.

None of the above are really barriers to getting sqm-scripts and gui
into some more mainline openwrt package repository, it had been my
full intent to get them into openwrt barrier breaker but I was
juggling far too many other things at the time of the first freeze to
accomplish that.

Certainly more testing on more platforms is needed ASAP, and I have
been appreciating the efforts of those doing so, while taking a bit of
a break from it all.

> There's some discussion of this here:
>
> https://github.com/dtaht/ceropackages-3.10/issues/8
>
> Testing is welcome!
>
>> · I believe fq-codel is integrated into the latest available versions
>> of Linux. If so, other than setting upload and download limits, do we
>> already have buffer control handled with all newer OpenWRT releases?
>
> Yes, fq_codel is included in the Linux kernel, and in Openwrt it is even
> the default.

Just as a note, it is not only the default, but modified to support a
default quantum of 300, rather than an MTU. This is quite reasonable
for an AP or STA, less so for a box running at 1000s of megabits.

And it's not clear that elsewhere in openwrt (say, on x86) certain
offloads are not turned off like TSO, GSO, GRO,
that can affect performance. This is done by the overlarge and quite
bloated "debloat" script in cerowrt and not in
mainline openwrt.

Lastly, fq_codel with the default 5 tuple hash is not the right thing
for a wifi AP, something that sorts on a per-sta basis would be better
- and there is much other work to be done in the wifi stack to improve
it.

> So if your router is actually at the bottleneck
> (physically), things should pretty much just work (in theory). However,
> most routers are *not* at the bottleneck; there tends to be a modem of
> some sort (whether cable, DSL or FIOS) in-between. Which is where

Finding devices that have good device drivers for each of these ISP
technologies would be nice.

> software rate-limiting (which is what SQM-scripts do) comes into play.
>
>> · If so, do we still need to download and configure the packages,
>> QOS-Scripts, and Luci-App-Qos? If so, do these packages do anything
>> besides allow the configuration of Upload and Download limits?
>
> Well, the QoS-script packages have some downsides and some upsides. The
> main upside is configurability, I think. Including things like manually
> classifying traffic etc. The downside is that it doesn't do IPv6 right,
> and that SQM-scripts does link layer adaptation right, which I don't
> think QoS-scripts do. Also, QoS-scripts is more complex and harder to
> configure (I think).
>
>> · If we can, in fact, control bufferbloat with OpenWRT and the latest
>> Qos-scripts and Luci-App-QOS, then would the integration of SQM into
>> OpenWRT provide much benefit in controlling bloat? If so, are there
>> still plans to make that happen.
>
> Well, I do believe there would be some merit to having SQM included (at
> least as an optional package) in openwrt. More testing is the main thing
> required, I think. And if we aim at completely replacing QoS-scripts,
> (some of) the configurability needs to be added to SQM.

I have longed to find a sane way to benchmark the hfsc approach qos-scripts
uses vs the htb scripts sqm uses vs the DRR approach free.fr uses.

And to find a faster rate limiter than any of them. I keep thinking something
at the BQL level would work...

>> I am very happy with the configuration of my home router running
>> CeroWRT on a Netgear WNDR-3800 (running close to the latest build), on
>> a Verizon FIOS connection at 75 Mbs Down / and 75 Mbs Up, and on
>> running pings with Speedtest notice a definate difference in latency
>> (very tight control) vs up to 100 ms latency.

I had found on the FIOS connection that ESR has that only downstream
shaping seemed needed.

> Is this with SQM enabled? That usually tops out at around ~50Mbps due to
> CPU limits...

>
> -Toke
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article