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

[Sebastian Moeller]

Hi Toke hi Frits,

just a few small things to add to Toke’s...

On Aug 25, 2014, at 14:53 , 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?
> 
> Don't think the plans have changed per se. More of a case of needing
> more testing to be included in Openwrt.
> 
> 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. 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
> software rate-limiting (which is what SQM-scripts do) comes into play.

	I do not think that all ethernet drivers for OpenWRT capable devices support byte queue limits (BQL) yet. Devices without BQL probably also need bandwidth shaping to work well.

> 
>> · 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.

	All correct, but note though that the l7-filters (for filtering on a per application basis) seem to be on the way out, I think that openwrt CC will not support them anymore. (And there seems to be doubts about how well the current l7 filtering still works (it seems the filter rules have not been updated in a long time); and for encrypted traffic they do not work at all. For these Reasons I think Gargoyle is actively recommending to avoid l7).

> 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.

	Note SQM’s link layer adjustments need to be checked for dual-stack IPv6 and IPv4 traffic on the wan port. (Which I would do except IPv6 does not work for me…)

> 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 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.
> 
> Is this with SQM enabled? That usually tops out at around ~50Mbps due to
> CPU limits…

	Curious as well…
Best Regards
	Sebastian

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