From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) (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 3C82A21F1C8 for ; Fri, 21 Dec 2012 09:13:42 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id fq11so5457010vbb.10 for ; Fri, 21 Dec 2012 09:13:41 -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=RLupYPSCobsKexaej/huaLO5++onh7kKeepoEq1Uwns=; b=F6dfhEpBYcNUVG/8cfZJNz+QrKlgVfOxkKcHfq+zuOJ46SVPUKXwfdmNhgbJohQqPd YKDMzn6x4Z3tRqM2DoRC2zNOJlOgJj02X9S+MKQpPqXGfgjKfH+oAnt2wJFD6kedJDHd avp7ATKPxs2TS7xZkAG2hTDP0I+x+iYBiw3/rCCaSvsNUKacleEBJpEIP4Fr7S0oBUct 37v0owtfFfp65p3IrZGcrkXa0aiRRybZb8rFIgx18xQFPUahVZdXE2GqPloQsm+tGwA7 EPjNZB/WO7Dn00PWqj2yGt8JYl0vN4AkqKJmmzapqtzptQY5C4NAI4qd4wulMwy1zDMm pZUQ== MIME-Version: 1.0 Received: by 10.52.91.142 with SMTP id ce14mr18298547vdb.84.1356110020865; Fri, 21 Dec 2012 09:13:40 -0800 (PST) Sender: gettysjim@gmail.com Received: by 10.58.116.135 with HTTP; Fri, 21 Dec 2012 09:13:40 -0800 (PST) In-Reply-To: <50D496FB.5090409@pollere.com> References: <50D496FB.5090409@pollere.com> Date: Fri, 21 Dec 2012 12:13:40 -0500 X-Google-Sender-Auth: Or058AWaXABAf65v3grvXq1zmZA Message-ID: From: Jim Gettys To: Kathleen Nichols Content-Type: multipart/alternative; boundary=20cf307f37e611efff04d15ff8a0 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 17:13:42 -0000 --20cf307f37e611efff04d15ff8a0 Content-Type: text/plain; charset=ISO-8859-1 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 > --20cf307f37e611efff04d15ff8a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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 dr= iver (which may have queuing in addition to that in the queue discipline.

In any case, that's my theory as to wha= t 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<= /a>> wrote:
On 12/21/12 2:32 AM, Dave Taht wrote:
> On Fri, Dec 21, 2012 at 5:19 AM, Alessandro Bolletta
> <alessandro@mediaspot.n= et> wrote:
...
>> Also, i tried to decrease interval and target op= tions in order to obtain a
>> latency, for connections estabilished while upload is flowing, low= er 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 t= o
be running
in the location of the actual queue!

I don't understand why you are lowering the target explicitly as the us= e of
an MTU's worth of packets as the alternate target appeared to work quit= e
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.

=A0 =A0 =A0 =A0 Kathie
___________________________________= ____________
Codel mailing list
Codel@lists.bufferbloat.net<= /a>
= https://lists.bufferbloat.net/listinfo/codel

--20cf307f37e611efff04d15ff8a0--