<div dir="ltr">We aren't adding the time in the device driver to the time spent in the rest of the queue.<div><br></div><div style>Right now, we don't have the time available that packets are queued in the device driver (which may have queuing in addition to that in the queue discipline.</div>
<div style><br></div><div style>In any case, that's my theory as to what is going on...</div><div style>                           - Jim</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Fri, Dec 21, 2012 at 12:06 PM, Kathleen Nichols <span dir="ltr"><<a href="mailto:nichols@pollere.com" target="_blank">nichols@pollere.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 12/21/12 2:32 AM, Dave Taht wrote:<br>
> On Fri, Dec 21, 2012 at 5:19 AM, Alessandro Bolletta<br>
> <<a href="mailto:alessandro@mediaspot.net">alessandro@mediaspot.net</a>> wrote:<br>
</div>...<br>
<div class="im">>> Also, i tried to decrease interval and target options in order to obtain a<br>
>> latency, for connections estabilished while upload is flowing, lower that 5<br>
>> ms.<br>
>><br>
>> So i set target at 2ms and interval to 5ms.<br>
><br>
> You are misunderstanding target and interval. These control the<br>
> algorithm for determining when to drop. interval is set to 100ms by<br>
> default as to try to find a good estimate for the RTT, and target to<br>
> 5ms as to have a goal for a maximum delay to aim for. These values<br>
> work well down to about 4Mbits, at which point we have been bumping<br>
> target up in relation to how long it takes to deliver a packet. A<br>
> value I've been using for target at 1Mbit has been 20, as it takes<br>
> 13ms to deliver a large packet.<br>
><br>
<br>
</div>Dave,<br>
<br>
Thanks for clarifying the target and interval. The notion of using a 2ms<br>
target<br>
and a 5ms interval boggles the mind and is precisely why we were looking<br>
for parameters that the user didn't have to fiddle. Of course, it has to<br>
be running<br>
in the location of the actual queue!<br>
<br>
I don't understand why you are lowering the target explicitly as the use of<br>
an MTU's worth of packets as the alternate target appeared to work quite<br>
well at rates down to 64kbps in simulation as well as in changing rates.<br>
I thought Van explained this nicely in his talk at IETF.<br>
<br>
        Kathie<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Codel mailing list<br>
<a href="mailto:Codel@lists.bufferbloat.net">Codel@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/codel" target="_blank">https://lists.bufferbloat.net/listinfo/codel</a><br>
</div></div></blockquote></div><br></div>