<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 21, 2012 at 1:57 PM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Dec 21, 2012 at 7:30 PM, Jim Gettys <<a href="mailto:jg@freedesktop.org">jg@freedesktop.org</a>> wrote:<br>

><br>
><br>
><br>
> On Fri, Dec 21, 2012 at 12:51 PM, Alessandro Bolletta<br>
> <<a href="mailto:alessandro@mediaspot.net">alessandro@mediaspot.net</a>> wrote:<br>
>><br>
>> Hi everybody,<br>
>> Thanks so much for your useful help! I solved my problem by reproducing<br>
>> bottleneck through HTB queues.<br>
>> I tried some bandwidth rates and i saw that target must be increased if<br>
>> the available bandwidth is <4mbps. 13ms is a good compromise for that<br>
>> situation.<br>
>> Also, i removed the switch from my testbed.<br>
>> Codel works amazingly well, congratulations for the job that has been<br>
>> done!<br>
>> I'll try to make more tests to ensure that it will be suitable for our<br>
>> needs; we are building a new wireless mesh network in Italy based on a<br>
>> totally new architecture and Codel could be a great improvement for queue<br>
>> management on the nodes.<br>
>><br>
>> Thanks again for your courtesy!<br>
>> Alessandro Bolletta<br>
><br>
><br>
> Kathy,<br>
><br>
> So in this case, there is another packet of buffering *under* the codel<br>
> queue in the HTB line discipline (which buffers one packet), plus whatever<br>
> additional buffering of there may be in the device driver (where the mileage<br>
> varies).<br>
<br>
</div>Which exits at line rate, so it's not a huge issue timewise,<br>
particularly in an age where cable modems are specced to run at gigE.<br></blockquote><div><br></div><div style>But the time the packet spends in HTB *is* significant in terms of time, and it's not going into the computation of the time in the queue. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> So codel isn't actually dropping the head of the queue, but the second (or<br>
> further) packet back, in effect.  So the control law computation won't be<br>
> quite right.<br>
>                           - Jim<br>
<br>
</div>It certainly is feasible to produce a version of fq_codel that is like<br>
tbf or htb internally. Eric figured it would be a couple dozen lines<br>
of code...<br></blockquote><div><br></div><div style>For htb that might be the "best" solution, since it is a case we're unfortunately going to be living with for quite a while. </div><div style><br></div><div style>
Then there is the time spent in the device driver; for example, John's hack Lantiq DSL driver with it's (current) two packets of buffering.</div><div style><br></div><div style>Those packets trickle out at DSL line rate (slow), not the fast speed of 100Mb or 1G ethernet being transmitted to a cable modem.</div>
<div style>                      - Jim</div><div style><br></div><div style><br></div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Actually it could be simpler in terms of interacting with the linux<br>
scheduler than those alternatives as we're doing timestamping anyway,<br>
so with an explicit bandwidth limit it's straightforward to predict<br>
when the next packet can be delivered at what re-scheduled time....<br>
<br>
It would save an unmanaged packet outstanding, too. Well, hmm, that<br>
would have to get looked at by the estimator...<br>
<br>
Use cases:<br>
<br>
1) ISPs artificially rate limit lines regardless<br>
2) So do virtual service providers<br>
3) our current need to reduce bandwidth to below the crappy device<br>
next in line..<br>
<br>
The last problem is so pervasive that I have a whole bunch of complex<br>
htb scripts to do it right. It would be easier to have a rate limited<br>
fq_codel (well, one that also does prioritization like pfifo_fast) and<br>
less cpu intensive to move all that logic out of the combination of<br>
fq_codel + htb and into one qdisc...<br>
<br>
just a thought...<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Dave Täht<br>
<br>
Fixing bufferbloat with cerowrt: <a href="http://www.teklibre.com/cerowrt/subscribe.html" target="_blank">http://www.teklibre.com/cerowrt/subscribe.html</a><div style="width:16px;height:16px;display:inline-block"> </div>
<br>
</div></div></blockquote></div><br></div></div>