From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 593C73B29E for ; Thu, 2 Nov 2017 04:25:41 -0400 (EDT) Received: from [192.168.250.101] ([134.76.241.253]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LsxuQ-1d7f700ING-012Z0B; Thu, 02 Nov 2017 09:25:40 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sebastian Moeller In-Reply-To: <50453bcb-dc99-ed8e-7a9b-e00ccbcdb550@yahoo.fr> Date: Thu, 2 Nov 2017 09:25:39 +0100 Cc: bloat@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <026B80D8-2452-4E9E-A85E-4FBD6BFB25A1@gmx.de> References: <50453bcb-dc99-ed8e-7a9b-e00ccbcdb550@yahoo.fr> To: Y X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:CRuXWTeWEHIvBiSqyXS62vKUvxxlDnT9JMpHhZMUBAbvOV6qs6r QO+zWOaV+DdSyQYHuHe+D0z/81P7CTg8aID3s0CxkM4JMETSsWIoZn/gTkLGyL7J8UfW9oq tgudk0sehBzkndIeiE2xjlsvWN4iS8Xq9li98ln7w3k6h1Wnf3PMkD/Zz5mVD8trXUHn6qD nIdnzo56ye+gHipn3PiAw== X-UI-Out-Filterresults: notjunk:1;V01:K0:FvtQWL3RhnY=:00IJ2uGF1+P8WszVX4P96m d1hNj8aDH0frqoxqXuE2abpN1VPeyQtH8P3hbnjFIRX0ILHcspb+yFnGv895C8YKb5N2AWI1C 6f+HrJzNCaiQgRKUgNikZxca+wvvJm6h1UW9cgLdeHxW27O6Nux/D4aPqvlv6UBdz4UgVdFA1 mO7xP0vV7H/fWko5/6TpsAo8ViR+x/F1HEoZme+zg2UNxtAybQddadcva1Fmoyb1IeYZfvmV5 Usv1AHPPGCibvKN9pZxA/rcqHt52ftElxZl4YRqFQby/N5Qp3skA9l6l5dmTwItQwVZrYNoZG Peh76TZo0NlIQhocSbEitTzXavyPvFKpG+qf03bWNdRKfhGx4Q5m4peuRN6wvEaUCVGNYB783 bnYxyd4yH3297RfL42mtDNsxPRjPQtJgmv+d/ICLCIqj0TgTw1ZokDjOQzu92ALQQJUSFizIp vfcTQehhgf2ND7Q+U5A5WGGJsoMfo7RbxR+3vMGtYMb8r7M/KbYnnfKd4FAXjnKHzcSwCe6Md 7jlCf7f6e/ALGNJ+udQCl8eHLd9Bd5go92ilzZxvX6XBDGhgLKbTYBtCV77vPThpNX6e3Gq0z xgfItz2vZvX63G8A1boqVzsvJrGtPeBw1GQoZRBR3PKTt9mqhOac9DY9zHqzT+EI0rHc3VT3x wFqIxj5Mk6AwxXI5kFsjmQ3a1EkmiZwCVwArRzzGcNC5qp4RR9PmSygNbR/CbZ7dNsfMwj60G DoczTA58r5ndwKSNWeBwGysetrc58jjsTgsUgq/Kf1XyMquOQhXHVQoUH3Gug43mS/oIf/j3F lM4pz5kGO1pkdOLJGQadB0xyT+PI5+Cck7MftECRTxf/wR702I= 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 08:25:41 -0000 Hi Y. > On Nov 2, 2017, at 07:42, Y wrote: >=20 > hi. >=20 > My connection is 810kbps( <=3D 1Mbps). >=20 > This is my setting For Fq_codel, > quantum=3D300 >=20 > target=3D20ms > interval=3D400ms >=20 > MTU=3D1478 (for PPPoA) > I cannot compare well. But A Latency is around 14ms-40ms. Under full saturation in theory you would expect the average = latency to equal the sum of upstream target and downstream target (which = in your case would be 20 + ???) in reality I often see something like = 1.5 to 2 times the expected value (but I have never inquired any deeper, = so that might be a measuring artifact)... Best Regards >=20 > Yutaka. >=20 > 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 = outperforms the "no knobs" fq_codel approach for connections with slow = upload speed. >>=20 >> When running a single file upload @350kbps , I've observed the = competing ICMP traffic quickly begin to drop (fq_codel) or be delayed = considerably ( under sfq). =46rom reading the tuning best practices page = is not optimized for this scenario. (<2.5mbps) >> = (https://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchm= arking_Codel_and_FQ_Codel/) fq_codel=20 >>=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). = People just flipping the fq_codel button on their router at these low = speeds could be doing themselves a disservice. >>=20 >> I've toyed with increasing the target and this does solve the = excessive drops. I haven't played with limit and quantum all that much.=20= >>=20 >> My go-to solution for this would be different classes, a.k.a. = traditional QoS. But , wouldn't it be possible to tune fq_codel punish = the large flows 'properly' for this very low bandwidth scenario? Surely = <1kb ICMP packets can squeeze through properly without being dropped if = there is 350kbps available, if the competing flow is managed correctly. >>=20 >> I could create a class filter by packet length, thereby moving = ICMP/VoIP 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? >>=20 >> Lowering Quantum below 1500 is confusing, serving a fractional packet = in a time interval? >>=20 >> Is there real value in tuning fq_codel for these connections or = should people migrate to something else like nfq_codel? >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Bloat mailing list >>=20 >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat