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

[Jonathan Morton <chromatix99@gmail.com>]

> 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

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

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

 - Jonathan Morton