<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 21, 2012 at 12:51 PM, Alessandro Bolletta <span dir="ltr"><<a href="mailto:alessandro@mediaspot.net" target="_blank">alessandro@mediaspot.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everybody,<br>
Thanks so much for your useful help! I solved my problem by reproducing bottleneck through HTB queues.<br>
I tried some bandwidth rates and i saw that target must be increased if the available bandwidth is <4mbps. 13ms is a good compromise for that situation.<br>
Also, i removed the switch from my testbed.<br>
Codel works amazingly well, congratulations for the job that has been done!<br>
I'll try to make more tests to ensure that it will be suitable for our needs; we are building a new wireless mesh network in Italy based on a totally new architecture and Codel could be a great improvement for queue management on the nodes.<br>

<br>
Thanks again for your courtesy!<br>
<span class="HOEnZb"><font color="#888888">Alessandro Bolletta</font></span></blockquote><div><br></div><div style>Kathy,</div><div style><br></div><div style>So in this case, there is another packet of buffering *under* the codel queue in the HTB line discipline (which buffers one packet), plus whatever additional buffering of there may be in the device driver (where the mileage varies).</div>
<div style><br></div><div style>So codel isn't actually dropping the head of the queue, but the second (or further) packet back, in effect.  So the control law computation won't be quite right.</div><div style>                          - Jim</div>
<div style><br></div></div><br></div></div>