From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) by lists.bufferbloat.net (Postfix) with ESMTPS id 772513C9F2 for ; Mon, 18 Jan 2016 09:08:16 -0500 (EST) Received: by mail-yk0-x22e.google.com with SMTP id a85so535845292ykb.1 for ; Mon, 18 Jan 2016 06:08:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=otvorenamreza-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=CReoGe+pmyoDSMNapBNBYyXH6R11vvbQq93US8D2h6s=; b=Jy0CUCA3iPlDErT71958ujOgL0V9Vk7+3i/in4cj8myeBtjnvxkurIQBVSFeWrL0ww qcz61lm+82wlylxSGnDHE8UgKJR0qyvJ6SFRw1U7J4f5P+RgbKv+1wsYwM8wJceGCBtV zPd/RafWMoYwUSyvyD3c4Z6t38ei66zws8TrW4kRIXOkYmRvFM28miKoHPavsPUM0TQY tr8gaourZgwd+Al9UDxn/WE0m/QbnuYvibPyJdU/JWL4kh5RE/Uc8uKmSy59isnA/KF3 6GSD+sHarn4CffWmcEiGJlXbtidhmNiVPxJCoSbZAxJUVEkh3Zi4mlryhH0axgBBUBQK /v8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=CReoGe+pmyoDSMNapBNBYyXH6R11vvbQq93US8D2h6s=; b=ZD/NgZ9kEpcyFq33Plx/N2rqiPGBVLeWbD+wLWqQvNCBbWDtWaieJXlOJd6ZIWoQw4 eL+ofIhSZ3kR/mte4oDKSOrik2zR25BNu6QQRJXFBmQMXm8IZFXsgnuHC5VRsPlYeMbY nSj/bRqHkiRtGDK8uQJpgl/8TbNNiztBDOm8ndVT46fqAYM3EZOiqChboEuTYT42lK3g YhuB9t2hAdfqHfppqrHGCcASqGhd2rNxVH1Aws24mutfGOMMXVzkBEHXTc0+0f84pEZ/ YgEDlxW1mBkXhwuwXVujjRFv/v1eDGR8wsBKvRsjKXNZv6J7TF3XgprYamUzlv238OHs x6Gg== X-Gm-Message-State: ALoCoQn45WGNyRTRpjH7g8LcqLcpq8+mBIdANAj/fnMFQCr3CO/a4DjoiS3/d3kyi7VZr6GKg2xUy7Ght1dvDbMNhG4HQy6GCw== X-Received: by 10.13.217.151 with SMTP id b145mr16872458ywe.226.1453126095906; Mon, 18 Jan 2016 06:08:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.114.7 with HTTP; Mon, 18 Jan 2016 06:07:36 -0800 (PST) X-Originating-IP: [93.141.157.81] In-Reply-To: References: <6737994D-CE0B-46F5-B55C-A584FF6A8014@gmail.com> From: Valent Turkovic Date: Mon, 18 Jan 2016 15:07:36 +0100 Message-ID: To: Jonathan Morton Cc: Outback Dingo , make-wifi-fast@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cerowrt-devel] routers you can throw off the back of a truck X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 14:08:16 -0000 Forgot one link :) [2] http://fatooh.org/esfq-2.6/ On Mon, Jan 18, 2016 at 3:07 PM, Valent Turkovic wrote: > On Mon, Jan 18, 2016 at 12:29 PM, Jonathan Morton = wrote: >> >>> On 18 Jan, 2016, at 11:43, Valent Turkovic w= rote: >>> >>> 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 bandwi= dth parameter to give it a sane starting point, say 1Mbit. I think some of= the more recent GUIs have a field for =E2=80=9Cadvanced=E2=80=9D or =E2=80= =9Cexperimental=E2=80=9D options like this. Once it sees some traffic, it = should settle down reasonably quickly to the real link capacity, minus a sm= all 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 traffi= c > 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 anyw= here? > >> As a reminder, autorate_ingress only works *downstream* of the bottlenec= k link. Use it on the external interface=E2=80=99s *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 th= e uplink capacity when it is saturated, and typical consumer traffic doesn= =E2=80=99t do that very often. If we did have a saturating bulk upstream T= CP flow, then we could examine its RTT profile in userspace, under the assu= mption 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 spee= d to some fixed fraction of that (using tc qdisc change, for least disrupti= on). 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=E2=80= =99re 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 intui= tive keywords to specify commonly-encountered RTT ranges; the one for =E2= =80=9Cinternet=E2=80=9D is 100ms, which corresponds to the Codel default pa= rameters. >> >> The 5ms figure is the target *queuing* latency, which should be consider= ably less than the estimated RTT; you really don=E2=80=99t want to be consi= stently adding 60ms of queuing on top of your 60ms inherent 3G latency. > > Thanks!