On Fri, Dec 21, 2012 at 2:13 PM, Kathleen Nichols <nichols@pollere.com>wrote:

>
> 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.
>

Could be: but since the driver and the queue disciple's above end up acting
as a single queue (there is no loss between the driver and the OS above),
these "coupled" queues will at a minimum throw off the square root
computation in proportion to the underlying delay if not accounted for.  So
I think the time does have to go into the computation (and is why Dave's
been having to mess with the target).

                                      - Jim


>
>         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
>
>
> >
> >
>
>