From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 DF9C53B29E for ; Thu, 2 Nov 2017 04:23:24 -0400 (EDT) Received: from [192.168.250.101] ([134.76.241.253]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MQRZw-1die050Xeu-00TkPq; Thu, 02 Nov 2017 09:23:21 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sebastian Moeller In-Reply-To: Date: Thu, 2 Nov 2017 09:23:20 +0100 Cc: bloat Content-Transfer-Encoding: quoted-printable Message-Id: <7C7F54C0-7EB2-493B-A1DD-2CB681331722@gmx.de> References: To: cloneman X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:JjewU6YX6Wk+BuICQopI5Ilb6NcA52dzN1fJqNv4kxhRwPoul32 VoJL7Xk+xiZILZP9r98RGN1mPJFWixIIM8EBMK0Z7kEjVQuQ+HngLHpPhvApnKUfbQfUccb 5tRTKcAlNRzYNkYwz31vg/M8NmGlqIqeqxGkERTrGrjdctkw/OC2WUmCTZUbeAlVssBU+PR vMc8BdI1EDPMGmnIp1Uow== X-UI-Out-Filterresults: notjunk:1;V01:K0:rOz0GeLHzvE=:2Ni3+bBrbt/zIn5l5fIdRg pWLRaSY4MEOEzmuXUrZtIu6ja3df7IdsSVecgtvXga4I4criYYa7NMtKuVhsfs0VdbCbWrJCp ltk/Bm1H7bv6f9dshmj086MB5AmX8EgaEQ02LzrDjh66GX/plkD8LxKsGnNuNYGmonhHERGRy 0nQuA5j3rBW7y2pSDpYYXHTYC9eL7FRN5+N3NT1xXur+r7Cv4xtOU7GUFJisvEl5LYRyzP9nX VvT7ESkz2eZ3ETDDfSVpZEnumE9ecyoHRlz5vlKF8XhS/A6/4Diq6R8W+nzfmYzgzMJPCg7+U wuHVuN25sCMbBhjQd2tiu2aEoTgf8/iGIpptpB8H4UF3DIU4NjSATqDgZJNgZ7EgqBZJj254L z0enTmGpYitL3yhGpwxZHFtXutTtStD/Hw8lnonIVFbZUXAPY/01xxKk//qcxNU3VjDo11LVC Kb/1a0qVo565xbJqf30O5IrmW1LqHUX8/PPwOuO3PVKF8Kh9JXAmDR1S6ks9kE/jTgkPiRm1N 7phfEUUJS3attkbRryTQ8AhgfLqFkWuqHttVOpQo4RccJBPH3bVcnKD0bRUN4nHZFDuczRiQ4 xjCFbcF801IztCJDe53jfEr72q1TnkWysOh8l12tqmatj8TmU9If3NfpWyLGMayynMQAjVYVE 2Bqw3gCcwVyYwDbKOkB+Jm0NSQnOK5nXGacUdolcTIBoZ67SKMcJ0dyIsGfNGy3qkEp7mn0Od G/rm7wmrbRbC3dmoMxNplO0jkonPGAOX3GaD5d1vPf8Th/pp785hRoCbxpitinNxSLl/NyTd4 e0L9WlW9UW/hOiYV2qJNCV1L91wQy0w0YHs+u271UerHO/DoQU= 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:23:25 -0000 Hi cloneman, > On Nov 2, 2017, at 07:01, cloneman wrote: >=20 > 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 This page was last updated 2014, it seems we learned a few = tricks since then. May I recommend you look into sqm-scripts (see = https://lede-project.org/docs/user-guide/sqm for a user guide) if only = to look at how we recommend to configure fq_codel currently. One of the biggest issues with fq_codel at slow speeds (exactly = speeds below (1526*8)/0.005 =3D 2441600 bps) is that even a single = packet might use up most of or even exceed the 5ms default "target" = duration that fq_codel/codel default to. This is a problem because = exceeding that time will cause fq_codel to switch into drop mode and = your experience will be choppy. We now recommend to simply increase = target to be at least around 1.5 MTU worth of transfer time, for fast = links this will be smaller than the default 5ms, so we do nothing but = for slower links it will not so we adjust things. fq_codel has no way of = knowing the available bandwidth and hence can not auto compensate for = that. >=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. I would in all modesty recommend that people rather look into = using sqm-scripts (at least if using lede/openwrt or other linux based = distributions) that should give a better starting point for their own = experiments and modifications. So I am not saying do not experiment = yousrseld, but rather start from a known decent starting point (also = sqm-scripts easily handles user supplied scripts and makes it quite = comfortable to get started with playing with qdisc's and traffic = shapers). >=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= Target is exactly the value of interest here (except it seems = reasonable to also adjust interval as target is supposed to be in the = range of 5-10% of interval, so if target changes, interval might need to = change as well) >=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. At 2.5Mbps one full MTU packet in transfer will make all other = flows with wueued packets exceed the default 5ms target and hence change = them into drop mode, extending target is the right thing to do here... = Other than that fq_codel does try to boost sparse flows, but you will = only see this once you extended target appropriately. >=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? Not dropping based on a feature like length will simply invite = abuse, so I would not go there. >=20 > Lowering Quantum below 1500 is confusing, serving a fractional packet = in a time interval? No not serving fractional packets, but taking multiple rounds = through the "scheduler" before a flow with a large queued packet will be = allows to send, this also should allow for smaller packets to squeeze = by faster (without affecting bandwidth fairness). >=20 > Is there real value in tuning fq_codel for these connections or should = people migrate to something else like nfq_codel? Again, maybe just use sqm-scripts might slove most of these = issues in a user friendly fashion. sqm-scripts also allows to easily use = the experimental cake qdisc which has quite a number of cool tricks up = its sleeve, like pirecing though NAT to get the "real" source and = destination IP addresses which can be used to easily configure a made in = which cake tries to achieve fairness by the number of concurrently = active internal host IPs (and that for many end users seems to be = sufficient to not having to bother any further with twiddling with = qos/q\aqm settings). Best Regards=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat