From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from homiemail-a52.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 986473B29E for ; Thu, 2 Nov 2017 02:01:54 -0400 (EDT) Received: from homiemail-a52.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a52.g.dreamhost.com (Postfix) with ESMTP id A1181600263D for ; Wed, 1 Nov 2017 23:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=flamingpc.com; h= mime-version:from:date:message-id:subject:to:content-type; s= flamingpc.com; bh=mZAt/I2/nEP3trQNc+Y8AKoalYU=; b=QTpFNgp6YtyS1F TaHgMiK81z7gWmuY5lEsPf8ouH7lZA/mB506cHAinoKFUXheMhT1fuB+XhMWTScn xU/YUlVoFE05Yh5yXmAm7PKWZaW9BiH2GFoAYIXx3V7mkOt9WXAyxzgc2FEXk4kb 2zsWCqv5Qz9YlBZ7jn2o7rHMASZJI= Received: from mail-ot0-f170.google.com (mail-ot0-f170.google.com [74.125.82.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: fpc_mail@flamingpc.com) by homiemail-a52.g.dreamhost.com (Postfix) with ESMTPSA id 86C8B600262C for ; Wed, 1 Nov 2017 23:01:53 -0700 (PDT) Received: by mail-ot0-f170.google.com with SMTP id i19so657849ote.13 for ; Wed, 01 Nov 2017 23:01:53 -0700 (PDT) X-Gm-Message-State: AJaThX4eer4+P+t4R6KJQNy0JmMgc+I7v0utwrybZ4HBE9NERRFbajkF 4QmuJ3WPkACNkfPn6VgRF+K/TupeerzELhOyMbU= X-Google-Smtp-Source: ABhQp+QSXs3R2N11bfe7wWE5q3Zbh5piMyYRkpXRoYWiZqNAIO8TTRmY61P5F5sdlbXXRI8xK5uvCuU6uSPrAbvG6rE= X-Received: by 10.157.30.195 with SMTP id n61mr1522659otn.385.1509602512968; Wed, 01 Nov 2017 23:01:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.73.132 with HTTP; Wed, 1 Nov 2017 23:01:52 -0700 (PDT) From: cloneman Date: Thu, 2 Nov 2017 02:01:52 -0400 X-Gmail-Original-Message-ID: Message-ID: To: bloat Content-Type: multipart/alternative; boundary="001a1137ae6a89c4ed055cf9b9f0" Subject: [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 06:01:54 -0000 --001a1137ae6a89c4ed055cf9b9f0 Content-Type: text/plain; charset="UTF-8" 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. 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). From reading the tuning best practices page is not optimized for this scenario. (<2.5mbps) ( https://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel/ ) fq_codel 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've toyed with increasing the target and this does solve the excessive drops. I haven't played with limit and quantum all that much. 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. 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? 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 should people migrate to something else like nfq_codel? --001a1137ae6a89c4ed055cf9b9f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm = trying to gather advice for people stuck on older connections. It appears t= hat having dedictated /micromanged tc classes greatly outperforms the "= ;no knobs" fq_codel approach for connections with=C2=A0 slow upload sp= eed.

When running a single file upload @350kbps , I've observe= d the competing ICMP traffic quickly begin to drop (fq_codel) or be delayed= considerably ( under sfq).=C2=A0From reading the tuning best practices pag= e is not optimized for this scenario. (<2.5mbps)
(https://www.bufferbloat.net/projects/codel/wiki/Best_practic= es_for_benchmarking_Codel_and_FQ_Codel/)=C2=A0fq_codel=C2=A0

Of part= icular concern is that a no-knobs SFQ works better for me than an untuned c= odel ( 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 the= mselves=C2=A0a disservice.
=
I've toye= d with increasing the target and this does solve the excessive drops. I hav= en't played with limit and quantum all that much.=C2=A0

My go-to solution for this would be different classes, a.k.a.= traditional QoS. But ,=C2=A0 wouldn't it be possible to tune fq= _codel punish the large flows 'properly' for this very low bandwidt= h scenario? Surely <1kb ICMP packets can squeeze through properly withou= t being dropped if there is 350kbps available, if the competing flow is man= aged correctly.

I could create a class filter by packet lengt= h, thereby moving ICMP/VoIP to its own tc class, but=C2=A0 this goes agains= t "no knobs" it seems like I'm re-inventing the wheel of fair= queuing - shouldn't the smallest flows never be delayed/dropped automa= tically?

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 should people migrate to somet= hing else like nfq_codel?









=
--001a1137ae6a89c4ed055cf9b9f0--