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 AC77C3CB35 for ; Thu, 2 Nov 2017 16:31:44 -0400 (EDT) Received: from hms-beagle2.lan ([80.135.75.10]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MIuft-1e7tJ80TEn-002YUU; Thu, 02 Nov 2017 21:31:43 +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: Date: Thu, 2 Nov 2017 21:31:41 +0100 Cc: Bloat@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <91DC6F64-931A-4D5F-8071-1FF6B838D814@gmx.de> References: <50453bcb-dc99-ed8e-7a9b-e00ccbcdb550@yahoo.fr> <026B80D8-2452-4E9E-A85E-4FBD6BFB25A1@gmx.de> To: Y X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:6NeoIM1EPzghPoSx2KDvzzTrIX9/snq3fkCG/ZFEQT4ThJin0lG TfeUsVV/t0I/JXXUH9weTzEEyBCUVYKQVHI32t8i/mZHJ67NPFQTXh1duge3PLQ1YUfP9DZ Q44QZt40WKzWP7LumePxV5zeBHc+2tu2FWDDujsLcZw89cvdvnAWNGB/MuLcTWVVwAaetbe INpT4BMehq4iK0a8evMaw== X-UI-Out-Filterresults: notjunk:1;V01:K0:k4jTLqn7LSM=:Meumj8ALLidq2XHd4erWJW zhNTbpPd6iPLUudYIAGEqiuxHxUt/FmYjAAeR8gsvZ2LuB1YOvVJX2a93jYREOHEg6MJQ1rYk n8oPXVkSaFeZA3A2TidO4NNzulPgB/T7GgVFD29XXFOvrKUxIkGoQIRkb6kD/JTtrww51jeYl 0Ffri+sPgIJtlLpjLubB41pTKS3OZ17i5Q9csbw1bl+aiywPudY1mS0ZjYrt600oyPdK1XoJR dMgleZpvye+rAse7k3E8J0DwyuDoRxFtHr03wtLF7zeqMlFmu0c7okizGi02LMki6p6PSjaPc cP0PR2yfaymgnwUumTklZQSFhZbR8U7TBVH/dOsdEDhEjD7Os+w2K54qSuuD0HwYxafNOc72M n3NXac2EWHux3hz0OSYdNnA9Q40PJ9KxbzWPHB+oxo0GOmeOdw9wtZvnkTfTX+Tf51vgkp7fo a2vjr5USzqRyPdBd+abwI3EaaeBTsigQ2oc21c4YnaoyylfjX9uYL2csXLgWHU4mh4Qrj307+ kUqW5kI/WV3CXVi0v7y/P3kdrGATRR/5voHRcx8CzD5aoaEYQxTko+PJ+KGjV960jO+uPHBNB 5b4AEnQCiB7lq4NOy+2DAlUGVv2QJxBsThnt6w+rCcEtLHwLg/pyv1xhJyP4LcgzZHPw7CobO T775N/K9p+jRJYDmhBEnM2XaWXHYWvrQMTaOfgogLcytkgj4xAw5P/RLx7jwLjf4H94dUwiTt 6ofUkapFfuT1GDtGUe7zwbQA9tob18TV2ZXkJ7N19zDPBxOjy2/MbbPzvdHxzN57ZAwkXq1am mYsfu/eEYK8AMEptvi0cTDNWIZT6LKAjUAWwm4HtrAQMt4XhXs= 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 20:31:45 -0000 Hi Yutaka, > On Nov 2, 2017, at 17:58, Y wrote: >=20 > Hi ,Moeller. >=20 > Fomula of target is 1643 bytes / 810kbps =3D 0.015846836. >=20 > It added ATM linklayer padding. >=20 > 16ms plus 4ms as my sence :P >=20 > My connection is 12mbps/1mbps ADSL PPPoA line. > and I set 7Mbps/810kbps for bypass router buffer. That sounds quite extreme, on uplink with the proper link layer = adjustments you should be able to go up to 100% of the sync rate as = reported by the modem (unless your ISP has another traffic shaper at a = higher level). And going from 12 to 7 is also quite extreme, given that = the ATM link layer adjustments will cost you another 9% of bandwidth. = Then again 12/1 might be the contracted maximal rate, what are the sync = rates as reported by your modem? >=20 > I changed Target 27ms Interval 540ms as you say( down delay plus = upload delay). I could be out to lunch, but this large interval seems = counter-intuitive. The idea (and please anybody correct me if I am = wrong) is that interval should be long enough for both end points to = realize a drop/ecn marking, in essence that would be the RTT of a flow = (plus a small add-on to allow some variation; in practice you will need = to set one interval for all flows and empirically 100ms works well, = unless most of your flows go to more remote places then setting interval = to the real RTT would be better. But an interval of 540ms seems quite = extreme (unless you often use connections to hosts with only satellite = links). Have you tried something smaller? >=20 > It works well , now . Could you post the output of "tc -d qdisc" and "tc -s qdisc = please" so I have a better idea what your configuration currently is? Best Regards Sebastian > Thank you. >=20 > Yutaka. >=20 > On 2017=E5=B9=B411=E6=9C=8802=E6=97=A5 17:25, Sebastian Moeller wrote: >> Hi Y. >>=20 >>=20 >>> 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)... >>=20 >> Best Regards >>=20 >>=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 >>>> 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 >>>> 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 >>> _______________________________________________ >>> Bloat mailing list >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat