From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9398B3CB35 for ; Thu, 2 Nov 2017 12:33:07 -0400 (EDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id B09109000C35; Thu, 2 Nov 2017 09:33:06 -0700 (PDT) Received: from kmnimac.local (c-73-189-83-226.hsd1.ca.comcast.net [73.189.83.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nichols@pollere.net) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 19C4D9000C34; Thu, 2 Nov 2017 09:33:06 -0700 (PDT) To: bloat@lists.bufferbloat.net References: <50453bcb-dc99-ed8e-7a9b-e00ccbcdb550@yahoo.fr> <026B80D8-2452-4E9E-A85E-4FBD6BFB25A1@gmx.de> From: Kathleen Nichols Message-ID: Date: Thu, 2 Nov 2017 09:33:05 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <026B80D8-2452-4E9E-A85E-4FBD6BFB25A1@gmx.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] Tuning fq_codel: are there more best practices for slow connections? (<1mbit) X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 16:33:07 -0000 On 11/2/17 1:25 AM, Sebastian Moeller wrote: > Hi Y. >=20 >=20 >> On Nov 2, 2017, at 07:42, Y wrote: >> >> hi. >> >> My connection is 810kbps( <=3D 1Mbps). >> >> This is my setting For Fq_codel, >> quantum=3D300 >> >> target=3D20ms >> interval=3D400ms >> >> MTU=3D1478 (for PPPoA) >> I cannot compare well. But A Latency is around 14ms-40ms. >=20 > Under full saturation in theory you would expect the average latency t= o equal the sum of upstream target and downstream target (which in your c= ase would be 20 + ???) in reality I often see something like 1.5 to 2 tim= es the expected value (but I have never inquired any deeper, so that migh= t be a measuring artifact)... An MTU packet would cause 14.6ms of delay. To cause a codel drop, you'd need to have a queue of more than one packet hang around for 400ms. I would suspect if you looked at the dynamics of the delay you'll see it going up and down and probably averaging to something less than two packet times. Delay vs time is probably going to be oscillatory. Is the unloaded RTT on the order of 2-300 ms? >=20 > Best Regards >=20 >=20 >> >> Yutaka. >> >> On 2017=E5=B9=B411=E6=9C=8802=E6=97=A5 15:01, cloneman wrote: >>> I'm trying to gather advice for people stuck on older connections. It= appears that having dedictated /micromanged tc classes greatly outperfor= ms the "no knobs" fq_codel approach for connections with slow upload spe= ed. >>> >>> When running a single file upload @350kbps , I've observed the compet= ing ICMP traffic quickly begin to drop (fq_codel) or be delayed considera= bly ( under sfq). From reading the tuning best practices page is not opti= mized for this scenario. (<2.5mbps) >>> (https://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_b= enchmarking_Codel_and_FQ_Codel/) fq_codel=20 >>> >>> Of particular concern is that a no-knobs SFQ works better for me than= an untuned codel ( more delay but much less loss for small flows). Peopl= e just flipping the fq_codel button on their router at these low speeds c= ould be doing themselves a disservice. >>> >>> I've toyed with increasing the target and this does solve the excessi= ve drops. I haven't played with limit and quantum all that much.=20 >>> >>> My go-to solution for this would be different classes, a.k.a. traditi= onal QoS. But , wouldn't it be possible to tune fq_codel punish the larg= e flows 'properly' for this very low bandwidth scenario? Surely <1kb ICMP= packets can squeeze through properly without being dropped if there is 3= 50kbps available, if the competing flow is managed correctly. >>> >>> I could create a class filter by packet length, thereby moving ICMP/V= oIP to its own tc class, but this goes against "no knobs" it seems like = I'm re-inventing the wheel of fair queuing - shouldn't the smallest flows= never be delayed/dropped automatically? >>> >>> Lowering Quantum below 1500 is confusing, serving a fractional packet= in a time interval? >>> >>> Is there real value in tuning fq_codel for these connections or shoul= d people migrate to something else like nfq_codel? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Bloat mailing list >>> >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat >> >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat >=20