<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>hi.</p>
<p>My connection is 810kbps( <= 1Mbps).</p>
<p>This is my setting For Fq_codel,<br>
</p>
<p>quantum=300</p>
<p>target=20ms<br>
interval=400ms</p>
<p>MTU=1478 (for PPPoA)<br>
</p>
<p>I cannot compare well. But A Latency is around 14ms-40ms.</p>
<p>Yutaka.<br>
</p>
<br>
<div class="moz-cite-prefix">On 2017年11月02日 15:01, cloneman wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CABQZMoL8McmUhCozpaTeS3qYcxndeA_5Z=g_xu=GdhvxbkFjTA@mail.gmail.com">
<div dir="ltr"><span style="color:rgb(0,0,0);font-size:12.8px">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.</span><br
style="color:rgb(0,0,0);font-size:12.8px">
<br style="color:rgb(0,0,0);font-size:12.8px">
<font color="#000000"><span style="font-size:12.8px">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)</span></font>
<div><font color="#000000"><span style="font-size:12.8px">(<a
href="https://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel/"
moz-do-not-send="true">https://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel/</a>) fq_codel </span></font><br>
<br>
<font color="#000000"><span style="font-size:12.8px">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.</span></font></div>
<div><font color="#000000"><span style="font-size:12.8px"><br>
</span></font></div>
<div>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.
<div><br style="color:rgb(0,0,0);font-size:12.8px">
<span style="color:rgb(0,0,0);font-size:12.8px">My go-to
solution for this would be different classes, a.k.a.<b> </b>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.<br>
</span><br>
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?</div>
<div><br>
</div>
<div>Lowering Quantum below 1500 is confusing, serving a
fractional packet in a time interval?<br>
<br>
Is there real value in tuning fq_codel for these connections
or should people migrate to something else like nfq_codel?<br>
<font color="#000000"><span style="font-size:12.8px"><br>
<br>
</span></font></div>
<div><br>
</div>
<div><br>
<br>
<br>
</div>
<div><br>
<br style="color:rgb(0,0,0);font-size:12.8px">
<br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bloat mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a>
<a class="moz-txt-link-freetext" href="https://lists.bufferbloat.net/listinfo/bloat">https://lists.bufferbloat.net/listinfo/bloat</a>
</pre>
</blockquote>
<br>
</body>
</html>