Re: [Codel] R: Making tests on Tp-link router powered by Openwrt svn

[Kathleen Nichols <nichols@pollere.com>]

This issue needs more study. I'm not at all convinced you want to add the
device driver time since CoDel is not controlling that queue. Instead,
that queue is experienced by CoDel as additional round trip delay. I
believe that would be better accounted for by a longer interval, that is
if there is generally some known additional (additional to network path
delay) delay, that implementation may need a longer interval.

	Kathie

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