Forgot one link :) [2] http://fatooh.org/esfq-2.6/
On Mon, Jan 18, 2016 at 3:07 PM, Valent Turkovic <val...@otvorenamreza.org> wrote: > On Mon, Jan 18, 2016 at 12:29 PM, Jonathan Morton <chromati...@gmail.com> > wrote: >> >>> On 18 Jan, 2016, at 11:43, Valent Turkovic <val...@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! _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
