From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4354721F107 for ; Fri, 21 Dec 2012 11:34:06 -0800 (PST) Received: by mail-vb0-f53.google.com with SMTP id b23so5415986vbz.26 for ; Fri, 21 Dec 2012 11:34:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xHMCgzMTPn+vgVuogJ39jqshHMXx4rerCGOl0CHBbzE=; b=YvkyhMlEUahrhImaDfPQe3bAp7k59cx+3bEn4UQUxlb2RxXuDfKY3Gdip9IDlsjwIo C4SpgyIE8YYhkPAS5NWnWRlUo30mjndnFiW8h2J7HrCabQQRBdPPwOJqrOfBEZ2RIHPr T+1B3Id/sejHeV/6TvWENe37Xj0H36xeNabj+Iy0EpbM8Hn46cYAL4qWDa0xt8kWubkq XASjXCfnaRMwHSZBZM3PpDD+OOUFroqMfWcaceOZcOkDJX7ZmMPZDPqw99pS5NGoWFMU +AIpELWv4gW4/2pSu3xUgtbRfjjbz49cyTuTj/pTCUSW/wP9q3oQdcYPaLC1ou4O87Po 5BfQ== MIME-Version: 1.0 Received: by 10.52.17.208 with SMTP id q16mr18743680vdd.46.1356118445005; Fri, 21 Dec 2012 11:34:05 -0800 (PST) Sender: gettysjim@gmail.com Received: by 10.58.116.135 with HTTP; Fri, 21 Dec 2012 11:34:04 -0800 (PST) In-Reply-To: <50D4B4C1.5090206@pollere.com> References: <50D496FB.5090409@pollere.com> <50D4B4C1.5090206@pollere.com> Date: Fri, 21 Dec 2012 14:34:04 -0500 X-Google-Sender-Auth: z89zsCRzyGK0oEfOHmZT9NbAqqY Message-ID: From: Jim Gettys To: Kathleen Nichols Content-Type: multipart/alternative; boundary=bcaec5040a123019c104d161ee0e Cc: "codel@lists.bufferbloat.net" Subject: Re: [Codel] R: Making tests on Tp-link router powered by Openwrt svn X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 19:34:06 -0000 --bcaec5040a123019c104d161ee0e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 21, 2012 at 2:13 PM, Kathleen Nichols 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 > > wrote: > > > > On 12/21/12 2:32 AM, Dave Taht wrote: > > > On Fri, Dec 21, 2012 at 5:19 AM, Alessandro Bolletta > > > > > 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 > > https://lists.bufferbloat.net/listinfo/codel > > > > > > > > --bcaec5040a123019c104d161ee0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



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

This issue needs more study. I'm not at all convinced you want to add t= he
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 d= isciple's above end up acting as a single queue (there is no loss betwe= en the driver and the OS above), these "coupled" queues will at a= minimum throw off the square root computation in proportion to the underly= ing delay if not accounted for. =A0So I think the time does have to go into= the computation (and is why Dave's been having to mess with the target= ).

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Jim
=A0=A0

=A0 =A0 =A0 =A0 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 i= n the
> rest of the queue.
>
> Right now, we don't have the time available that packets are queue= d 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...
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- Jim
>
>
>
> On Fri, Dec 21, 2012 at 12:06 PM, Kathleen Nichols <nichols@pollere.com
> <mailto:nichols@pollere.com>> wrote:
>
> =A0 =A0 On 12/21/12 2:32 AM, Dave Taht wrote:
> =A0 =A0 > On Fri, Dec 21, 2012 at 5:19 AM, Alessandro Bolletta
> =A0 =A0 > <alessandro@mediaspot.net <mailto:alessandro@mediaspot.net>> wrote: > =A0 =A0 ...
> =A0 =A0 >> Also, i tried to decrease interval and target options= in order to
> =A0 =A0 obtain a
> =A0 =A0 >> latency, for connections estabilished while upload is= flowing,
> =A0 =A0 lower that 5
> =A0 =A0 >> ms.
> =A0 =A0 >>
> =A0 =A0 >> So i set target at 2ms and interval to 5ms.
> =A0 =A0 >
> =A0 =A0 > You are misunderstanding target and interval. These contr= ol the
> =A0 =A0 > algorithm for determining when to drop. interval is set t= o 100ms by
> =A0 =A0 > default as to try to find a good estimate for the RTT, an= d target to
> =A0 =A0 > 5ms as to have a goal for a maximum delay to aim for. The= se values
> =A0 =A0 > work well down to about 4Mbits, at which point we have be= en bumping
> =A0 =A0 > target up in relation to how long it takes to deliver a p= acket. A
> =A0 =A0 > value I've been using for target at 1Mbit has been 20= , as it takes
> =A0 =A0 > 13ms to deliver a large packet.
> =A0 =A0 >
>
> =A0 =A0 Dave,
>
> =A0 =A0 Thanks for clarifying the target and interval. The notion of u= sing a 2ms
> =A0 =A0 target
> =A0 =A0 and a 5ms interval boggles the mind and is precisely why we we= re looking
> =A0 =A0 for parameters that the user didn't have to fiddle. Of cou= rse, it has to
> =A0 =A0 be running
> =A0 =A0 in the location of the actual queue!
>
> =A0 =A0 I don't understand why you are lowering the target explici= tly as the
> =A0 =A0 use of
> =A0 =A0 an MTU's worth of packets as the alternate target appeared= to work quite
> =A0 =A0 well at rates down to 64kbps in simulation as well as in chang= ing rates.
> =A0 =A0 I thought Van explained this nicely in his talk at IETF.
>
> =A0 =A0 =A0 =A0 =A0 =A0 Kathie
> =A0 =A0 _______________________________________________
> =A0 =A0 Codel mailing list
> =A0 =A0 Cod= el@lists.bufferbloat.net <mailto:Codel@lists.bufferbloat.net>
> =A0 =A0 https://lists.bufferbloat.net/listinfo/codel
=A0

>
>


--bcaec5040a123019c104d161ee0e--