From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic302-20.consmr.mail.ir2.yahoo.com (sonic302-20.consmr.mail.ir2.yahoo.com [87.248.110.83]) (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 7B50A3CB35 for ; Thu, 2 Nov 2017 12:53:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s2048; t=1509641637; bh=CHvtGWdlESugTHxhn0XcyfsLPLZs+N7n2wWk4cm31Yk=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=lI9bcBeYWOy4e6RTeuyvxpWJyRyD5QVGjvL70cl4iKBwb0Wu7mxNf5OKk867XP94dFCets80j7G/PYi2l0AsD9S8ZWlGxlOXmoG89qNGl7+vPwsjcTRoPUO9YRrNzTb3WHwJdWFmfQm9uV4RPyoLn8ysblbccCzAzOqN4MyxBSuXhDOrEVXRMo4AZojiGnFit3V9gQKoszLG9evx1u9dYwAXgiRtvJlcZoulUV5fG/FvnthYjv2SMyCAwsKgF+gF+tf6KOiV2492ZJAkyNXE4ORhEdHyMz2g/Ig7fm7NG5hyXfwKsRhaaC6bZPaO7qIfOlkg2QWYs2/GAWxS2oqKMw== X-YMail-OSG: mDjaiosVM1m6k6DvKAOUX2BwOv4ZAJjppyyW9OtkYjCikZBlKQvd7eEc4kCVnWK rOfLrdgAt3hl7oOmaP8bXbEvNUeOQkI.d2jEmtNy844r.wegmGj22rDGw8ZYR868f.CikZewNekl xcnc4LEv3lewnFoKeJdcaPWkdmX7E3uxWtpSU0.1_nZBto0M7f3BNVTWxX4h0Jy0Ty55PFUhMtsc jqwIVdswtK4.QQDkCasaibZwp7PK2ATVPkXZhP1yjEJgPUy2gzEDtK0czxRaA7OQMKPk7Dz9bYCQ GPrb7fpSPrwcc7HAmgJ7FTgUiWHX4Uv3nfC8Z0g2CWKVCyBes1XNE1SoWbTpF_taRw2AOQFGxOy8 iIN5AmRgm0WVx3XcxzsWRcVUKX_PjKhRpcFYhr5AoDr.aAgzoHHswCJBCr9bdeZ45udsa4jGRfpE rvh3m9xAJqZeLfexpJ1xe3p2O30MYngjbQn6SSz2C0wmuqbvR4Y8UQCOoXa03X5HNgeY8K_zO8F8 TmmXlzNopxte5zuBPXbQhBWorYLVMoVA91L37sxI7zEVI0jPjwsr4mQM5UL1yOcRIYOfh15UIbEV Y1w-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ir2.yahoo.com with HTTP; Thu, 2 Nov 2017 16:53:57 +0000 Received: from [127.0.0.1] by smtp129.mail.ir2.yahoo.com with NNFMP; 02 Nov 2017 16:53:55 -0000 X-Yahoo-Newman-Id: 165633.5691.bm@smtp129.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: mDjaiosVM1m6k6DvKAOUX2BwOv4ZAJjppyyW9OtkYjCikZB lKQvd7eEc4kCVnWKrOfLrdgAt3hl7oOmaP8bXbEvNUeOQkI.d2jEmtNy844r .wegmGj22rDGw8ZYR868f.CikZewNeklxcnc4LEv3lewnFoKeJdcaPWkdmX7 E3uxWtpSU0.1_nZBto0M7f3BNVTWxX4h0Jy0Ty55PFUhMtscjqwIVdswtK4. QQDkCasaibZwp7PK2ATVPkXZhP1yjEJgPUy2gzEDtK0czxRaA7OQMKPk7Dz9 bYCQGPrb7fpSPrwcc7HAmgJ7FTgUiWHX4Uv3nfC8Z0g2CWKVCyBes1XNE1So WbTpF_taRw2AOQFGxOy8iIN5AmRgm0WVx3XcxzsWRcVUKX_PjKhRpcFYhr5A oDr.aAgzoHHswCJBCr9bdeZ45udsa4jGRfpErvh3m9xAJqZeLfexpJ1xe3p2 O30MYngjbQn6SSz2C0wmuqbvR4Y8UQCOoXa03X5HNgeY8K_zO8F8TmmXlzNo pxte5zuBPXbQhBWorYLVMoVA91L37sxI7zEVI0jPjwsr4mQM5UL1yOcRIYOf h15UIbEVY1w-- X-Yahoo-SMTP: R8REcOaswBA8tpUVQfvLNOMJ0vXRwYHSeLQ- To: bloat@lists.bufferbloat.net References: <50453bcb-dc99-ed8e-7a9b-e00ccbcdb550@yahoo.fr> <026B80D8-2452-4E9E-A85E-4FBD6BFB25A1@gmx.de> From: Y Message-ID: Date: Fri, 3 Nov 2017 01:53:50 +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: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 16:53:58 -0000 Hi , Kathleen. Fomula of target is 1643 bytes / 810kbps = 0.015846836. It added ATM linklayer padding. On 2017年11月03日 01:33, Kathleen Nichols wrote: > On 11/2/17 1:25 AM, Sebastian Moeller wrote: >> Hi Y. >> >> >>> On Nov 2, 2017, at 07:42, Y wrote: >>> >>> 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. >> 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)... > 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? (When I do speedtest upload with ping to 8.8.8.8) Ping RTT is around 30ms-80ms. Avarage is around 40ms-50ms. There is not 100ms over delay. > Delay vs time is probably going to be oscillatory. yes :) >> Best Regards >> >> >>> 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 >>> _______________________________________________ >>> 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 >> > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat