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

[Valent Turkovic <valent@otvorenamreza.org>]

Forgot one link :)

[2] http://fatooh.org/esfq-2.6/

On Mon, Jan 18, 2016 at 3:07 PM, Valent Turkovic
<valent@otvorenamreza.org> wrote:
> On Mon, Jan 18, 2016 at 12:29 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>>
>>> On 18 Jan, 2016, at 11:43, Valent Turkovic <valent@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!