From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic310-12.consmr.mail.ir2.yahoo.com (sonic310-12.consmr.mail.ir2.yahoo.com [77.238.177.33]) (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 67F2A3B29E for ; Thu, 2 Nov 2017 02:42:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s2048; t=1509604937; bh=l9bhliCZ3plFII4+OwNOagFcivkopq0cqqo0Q0z0cig=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=OamIXEd46BvleY/vFfvuxeXUH1wSmBN13dc3zC5QTiRymziZotyvrcpxGUKYnRuhOo5dPCwmFG9tFG5bXE0R3C7VVVGd5FA5hAYadEK4DdxXFUm33vFa8KenpKv1l59DyGnjhCcfCQuv2hni2rL4wnroOou1m4XsmttoiyE0kW3tR5JaxYCbmT70O3wxWuG45+/YI09VQHFy/lO638yfMOKf5OaycXfGFYTHOQRIZX9r4FODoV/bHPN1XUgBGoGdlkmnOz/xOEl0psxcfz4+5ihJnrZd17HJahNalz5HyB8EW8WG2ruyAGldf/Dtz/cC7hGAOukc16VQeDVSi1I1eQ== X-YMail-OSG: 7lHH3IUVM1njpeiR9r55tKqvDrMTNnCxxng3eL.mpHN8KuhrhNy_dQBhC94uNQd jbdgoHxxOPZ_SglMYRkhT.sI8huFjRBmFEY9MsOGvtlZIczg6GfoznV1yhzut2BHK4d4aMMsoev4 apKKbLyik1jvywVVjLL6h5R7u5QOchlub6F_YFmB0YJy1ErPFHMK3c5y1KanSWi6Q.6KcyefB7FS B9ViYFpYL5l_Nc6v.z2GKM9ufZfcWMXOq2RBSyK9jz7d9v.Gk648dKKKVE9FctVO3vcbxqhDRO5f COzvG6Z_OaiSpz1A82h9O5sKTdpY2tmM2dFqx2qrwUpUZ6r0OCyN6T6XDIJpUWUuonIFOHtyqk5N A15pbZVuTQo5eucocC7KkmgIkkC68hiE6aImDMBniLOJwf7UD.NM1wRKSfcF7o95ln4V9mnaKA7e nOCr2X64ZAvM_ziw_.qombpr4F5WwFOJep6eIwHceSJeJRqlpQJIfpWmriXdiEQHg.02tUe9b9ZA O2Nm42MjqrTHpMkTGzMt.5rn1tuA3FM_JJ7aUhMRup81at7ePXKNwnmnCMqFaHYCcGkF6PMYuLZh 3bw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ir2.yahoo.com with HTTP; Thu, 2 Nov 2017 06:42:17 +0000 Received: from [127.0.0.1] by smtp101.mail.ir2.yahoo.com with NNFMP; 02 Nov 2017 06:42:15 -0000 X-Yahoo-Newman-Id: 396705.70956.bm@smtp101.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 7lHH3IUVM1njpeiR9r55tKqvDrMTNnCxxng3eL.mpHN8Kuh rhNy_dQBhC94uNQdjbdgoHxxOPZ_SglMYRkhT.sI8huFjRBmFEY9MsOGvtlZ Iczg6GfoznV1yhzut2BHK4d4aMMsoev4apKKbLyik1jvywVVjLL6h5R7u5QO chlub6F_YFmB0YJy1ErPFHMK3c5y1KanSWi6Q.6KcyefB7FSB9ViYFpYL5l_ Nc6v.z2GKM9ufZfcWMXOq2RBSyK9jz7d9v.Gk648dKKKVE9FctVO3vcbxqhD RO5fCOzvG6Z_OaiSpz1A82h9O5sKTdpY2tmM2dFqx2qrwUpUZ6r0OCyN6T6X DIJpUWUuonIFOHtyqk5NA15pbZVuTQo5eucocC7KkmgIkkC68hiE6aImDMBn iLOJwf7UD.NM1wRKSfcF7o95ln4V9mnaKA7enOCr2X64ZAvM_ziw_.qombpr 4F5WwFOJep6eIwHceSJeJRqlpQJIfpWmriXdiEQHg.02tUe9b9ZAO2Nm42Mj qrTHpMkTGzMt.5rn1tuA3FM_JJ7aUhMRup81at7ePXKNwnmnCMqFaHYCcGkF 6PMYuLZh3bw-- X-Yahoo-SMTP: R8REcOaswBA8tpUVQfvLNOMJ0vXRwYHSeLQ- To: bloat@lists.bufferbloat.net References: From: Y Message-ID: <50453bcb-dc99-ed8e-7a9b-e00ccbcdb550@yahoo.fr> Date: Thu, 2 Nov 2017 15:42:10 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DAC692D73D17B244F7CA2E3D" Content-Language: en-US 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 06:42:19 -0000 This is a multi-part message in MIME format. --------------DAC692D73D17B244F7CA2E3D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit hi. My connection is 810kbps( <= 1Mbps). This is my setting For Fq_codel, quantum=300 target=20ms interval=400ms MTU=1478 (for PPPoA) I cannot compare well. But A Latency is around 14ms-40ms. Yutaka. On 2017年11月02日 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. > > 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? > > > > > > > > > > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --------------DAC692D73D17B244F7CA2E3D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

hi.

My connection is 810kbps( <= 1Mbps).

This is my setting For Fq_codel,

quantum=300

target=20ms
interval=400ms

MTU=1478 (for PPPoA)

I cannot compare well. But A Latency is around 14ms-40ms.

Yutaka.


On 2017年11月02日 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.

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?











_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

--------------DAC692D73D17B244F7CA2E3D--