From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) by lists.bufferbloat.net (Postfix) with ESMTPS id D01E43C9F1; Mon, 18 Jan 2016 06:29:10 -0500 (EST) Received: by mail-lf0-x234.google.com with SMTP id m198so170141945lfm.0; Mon, 18 Jan 2016 03:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1m8S7AkrkmHCxeq77Uzq0m6NL6A3LAAzdGzQIzjIykU=; b=NwKDFyXbOwuBR40oH37id8VhEPGxk5OgreMtQ9YqG5LoWACM9+IAogVdM7R6FgQlM/ /A9ZkP7vM0emB6+h+IGjgbdMz64eWAok547d4Zud4zxPahyFvmrn/yMWOxMW/a+bU/if fIygkkT8hiQgOrS4qsGI0OLkB9nrxzWHa8NVq5vezT5WVQcXS5iQhjRp+Zoi0G+j8Vwi 0yfd1NYZsP5mdrXdY5V1Qt5T7sYdDDlKr5+ub/tprKnkSeKHxpkdBrgEixpcmIAazk05 K9+tJevuOMxTxnLzX7T/Vc03KGdkxnCD5d7sYPwLE/2ecdxwQM3RDnOAhL3ueK8IXTyB u5iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=1m8S7AkrkmHCxeq77Uzq0m6NL6A3LAAzdGzQIzjIykU=; b=mm0nu9sqh/XGtPcVUFx/zUR6jfvVRqunRD8UKZRNESK9GkTaebT94wHoWVq9gz2/oR lA7tBiMcY/W8Q9VjbGcsWStQGOPS+I4d2wzJY2D4eVmWTbDzTHRLb+igi2CMDy3/FiVa PabPS85lkc9ql8XTen4W7EnzWUIN9OFV+crLrxupQo3kQ0dPVqTlfJam073X0oGgu6YD a9Ad2XSHnfBXsXpaWRgsADwmxfDmXwW3vqMWHZX2daICiOfWfd8ZkXaG+9TZhiF+et5i xaJhgJaShiBhtgRtmmI5Y0dHgWTFCrM84wFVtoyJRNcIe6jCITkdk60zyVPkzms/Stj5 t0bw== X-Gm-Message-State: AG10YORfQJjaxf3a+yx/4iG5BScGnUz8ltFS4o0i8nID7HdfTlbSug7t4yCY682Vngv9jw== X-Received: by 10.25.170.203 with SMTP id t194mr6065094lfe.48.1453116549142; Mon, 18 Jan 2016 03:29:09 -0800 (PST) Received: from [192.168.238.201] (37-33-99-74.bb.dnainternet.fi. [37.33.99.74]) by smtp.gmail.com with ESMTPSA id 130sm3099746lff.31.2016.01.18.03.29.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Jan 2016 03:29:08 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Jonathan Morton In-Reply-To: Date: Mon, 18 Jan 2016 13:29:05 +0200 Cc: Outback Dingo , make-wifi-fast@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net" Content-Transfer-Encoding: quoted-printable Message-Id: References: <6737994D-CE0B-46F5-B55C-A584FF6A8014@gmail.com> To: Valent Turkovic X-Mailer: Apple Mail (2.3112) Subject: Re: [Make-wifi-fast] [Cerowrt-devel] routers you can throw off the back of a truck X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 11:29:11 -0000 > On 18 Jan, 2016, at 11:43, Valent Turkovic = wrote: >=20 > 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 =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 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=E2=80=99s *ingress* = if possible. > =46rom 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=E2=80=99t 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=E2=80=99= 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 =E2=80=9Cinternet=E2=80=9D 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=E2=80=99t want = to be consistently adding 60ms of queuing on top of your 60ms inherent = 3G latency. - Jonathan Morton