[Cerowrt-devel] routers you can throw off the back of a truck

[Valent Turkovic]

On Mon, Jan 18, 2016 at 12:29 PM, Jonathan Morton <chromatix99 at gmail.com> wrote:
>
>> On 18 Jan, 2016, at 11:43, Valent Turkovic <valent at otvorenamreza.org> wrote:
>>
>> Can you please share your sqm qos script, or just how you invoke tc
>> manually and I'll test it on my routers and see what happens then:)
>
> The autorate_ingress option is just a flag.  Specify it after the bandwidth parameter to give it a sane starting point, say 1Mbit.  I think some of the more recent GUIs have a field for “advanced” or “experimental” options like this.  Once it sees some traffic, it should settle down reasonably quickly to the real link capacity, minus a small margin to establish itself as the bottleneck.
>
> Eg: tc qdisc replace dev ifb0 root cake bandwidth 1Mbit autorate_ingress

# tc qdisc replace dev eth0.2 root cake bandwidth 1Mbit autorate_ingress
Unknown qdisc "cake", hence option "bandwidth" is unparsable

So this is the reason I saw "bad" results when using cake... cake
qdisc isn't even available in latest Chaos Chalmer... but Luci shows
it as an option, really strange.
Cake script [1] is located in /usr/lib/sqm/piece_of_cake.qos but there
is no cake kernel module as far as I can see:

# opkg list | grep sched
kmod-sched - 3.18.20-1 - Extra kernel schedulers modules for IP traffic
kmod-sched-connmark - 3.18.20-1 - Traffic shaper conntrack mark support
kmod-sched-core - 3.18.20-1 - Core kernel scheduler support for IP traffic
kmod-sched-esfq - 3.18.20-1 - Traffic shaper ESFQ support

Again trough accidental discovery it looks like ESFQ [2] would also be
an nice addition to codel. How about efq_codel insead of fq_codel ?
Has anybody tried using ESFQ with codel?

But back to OpenWrt... are there Cake packages for OpenWrt available anywhere?

> As a reminder, autorate_ingress only works *downstream* of the bottleneck link.  Use it on the external interface’s *ingress* if possible.
>

I'll try this as soon as I get cake working on OpenWrt...


>> From your presentation I see that if we had a daemon working in
>> background and somehow measured tcp latency (how?) and then we could
>> use it to raise/lower bandwidth limits on cake until we get best
>> possible results. Ideally I would like to use a queueing mechanism
>> that auto-configures everything.
>
> Right.  The autorate_ingress feature works entirely in kernelspace, and effectively takes care of the downstream half of the equation. The upstream half turns out to be a much harder problem, because we can only measure the uplink capacity when it is saturated, and typical consumer traffic doesn’t do that very often.  If we did have a saturating bulk upstream TCP flow, then we could examine its RTT profile in userspace, under the assumption that the downlink was taken care of.
>
> One reasonable approach might be to use a userspace tool to periodically scrape the downlink speed out of autorate_ingress, and set the uplink speed to some fixed fraction of that (using tc qdisc change, for least disruption).  It might even make sense for 3G to inherently have such a ratio.  If it does, does anyone know what it is?
>
>> @everybody any ideas how to tweak current "simple.qos" and
>> "simplest.qos" scripts in OpenWrt for 3G and fiber optics? On fiber
>> optic connection idle latency is around 30ms and on 3G connection is
>> around 60ms, do I need to change 5ms default in fq_codel to these
>> values? How?
>
> These are essentially internet-scale latencies, especially if you’re just pinging the gateway immediately beyond the link, so the defaults will work fine.  The most recent versions of tc-adv include a set of intuitive keywords to specify commonly-encountered RTT ranges; the one for “internet” is 100ms, which corresponds to the Codel default parameters.
>
> The 5ms figure is the target *queuing* latency, which should be considerably less than the estimated RTT; you really don’t want to be consistently adding 60ms of queuing on top of your 60ms inherent 3G latency.

Thanks!