From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) (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 2657621F0F2 for ; Fri, 21 Dec 2012 11:29:53 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so5524223vbb.17 for ; Fri, 21 Dec 2012 11:29:51 -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=zYyaLEoXUKk+5z4LS/0ICTyid0U0xezLxvOJTjWil/g=; b=Cp2Z+IMHwl+x3ynjwZ7u/pBUXFXqw0GVVLfsauiLZU8mFFVDsXvAHDtFoqQmwvFkc6 M56RzkAVaKIfhMgxhd3Pzy3nzy4izS54MoHrlnXCXSV5XwD+qi1YCCS+h7fVmmQZckHZ Egh7ItG+jdTGmCcwFXReWdmZCkFTymiSLkVWtmp1XVs+7OvFFk0WA1qvzzPsluV8UAw2 mw+g5OihfUnW47WGKNOVzOR0c0MUUCdbIBa6/gD1Fzqba0VaDd7fWp+aGFusEEQYjW2n eZfGos5N1unH7uTP15EDEsUlRv/WsmmAx1HCDeAuwLidVzFyG4e+WLOUxYu5EfE8QtaF amLQ== MIME-Version: 1.0 Received: by 10.58.222.40 with SMTP id qj8mr22138634vec.36.1356118191824; Fri, 21 Dec 2012 11:29:51 -0800 (PST) Sender: gettysjim@gmail.com Received: by 10.58.116.135 with HTTP; Fri, 21 Dec 2012 11:29:51 -0800 (PST) In-Reply-To: References: <2lps03vacpqmtehlf4gnq634.1356112034562@email.android.com> Date: Fri, 21 Dec 2012 14:29:51 -0500 X-Google-Sender-Auth: 1deP4dNJZTcs8uD4NV2ZaWicB0I Message-ID: From: Jim Gettys To: Dave Taht Content-Type: multipart/alternative; boundary=047d7bdc8fd018dedb04d161df3e 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:29:53 -0000 --047d7bdc8fd018dedb04d161df3e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Dec 21, 2012 at 1:57 PM, Dave Taht wrote: > On Fri, Dec 21, 2012 at 7:30 PM, Jim Gettys wrote: > > > > > > > > On Fri, Dec 21, 2012 at 12:51 PM, Alessandro Bolletta > > wrote: > >> > >> Hi everybody, > >> Thanks so much for your useful help! I solved my problem by reproducin= g > >> bottleneck through HTB queues. > >> I tried some bandwidth rates and i saw that target must be increased i= f > >> the available bandwidth is <4mbps. 13ms is a good compromise for that > >> situation. > >> Also, i removed the switch from my testbed. > >> Codel works amazingly well, congratulations for the job that has been > >> done! > >> I'll try to make more tests to ensure that it will be suitable for our > >> needs; we are building a new wireless mesh network in Italy based on a > >> totally new architecture and Codel could be a great improvement for > queue > >> management on the nodes. > >> > >> Thanks again for your courtesy! > >> Alessandro Bolletta > > > > > > Kathy, > > > > So in this case, there is another packet of buffering *under* the codel > > queue in the HTB line discipline (which buffers one packet), plus > whatever > > additional buffering of there may be in the device driver (where the > mileage > > varies). > > Which exits at line rate, so it's not a huge issue timewise, > particularly in an age where cable modems are specced to run at gigE. > But the time the packet spends in HTB *is* significant in terms of time, and it's not going into the computation of the time in the queue. > > > So codel isn't actually dropping the head of the queue, but the second > (or > > further) packet back, in effect. So the control law computation won't = be > > quite right. > > - Jim > > It certainly is feasible to produce a version of fq_codel that is like > tbf or htb internally. Eric figured it would be a couple dozen lines > of code... > For htb that might be the "best" solution, since it is a case we're unfortunately going to be living with for quite a while. Then there is the time spent in the device driver; for example, John's hack Lantiq DSL driver with it's (current) two packets of buffering. Those packets trickle out at DSL line rate (slow), not the fast speed of 100Mb or 1G ethernet being transmitted to a cable modem. - Jim > Actually it could be simpler in terms of interacting with the linux > scheduler than those alternatives as we're doing timestamping anyway, > so with an explicit bandwidth limit it's straightforward to predict > when the next packet can be delivered at what re-scheduled time.... > > It would save an unmanaged packet outstanding, too. Well, hmm, that > would have to get looked at by the estimator... > > Use cases: > > 1) ISPs artificially rate limit lines regardless > 2) So do virtual service providers > 3) our current need to reduce bandwidth to below the crappy device > next in line.. > > The last problem is so pervasive that I have a whole bunch of complex > htb scripts to do it right. It would be easier to have a rate limited > fq_codel (well, one that also does prioritization like pfifo_fast) and > less cpu intensive to move all that logic out of the combination of > fq_codel + htb and into one qdisc... > > just a thought... > > -- > Dave T=E4ht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html > > > --047d7bdc8fd018dedb04d161df3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Dec 21, 2012 at 1:57 PM, Dave Taht <dave.taht@gmail.com<= /a>> wrote:
On Fri, Dec 21, 2012 at 7:= 30 PM, Jim Gettys <jg@freedesktop.= org> wrote:
>
>
>
> On Fri, Dec 21, 2012 at 12:51 PM, Alessandro Bolletta
> <alessandro@mediaspot.n= et> wrote:
>>
>> Hi everybody,
>> Thanks so much for your useful help! I solved my problem by reprod= ucing
>> bottleneck through HTB queues.
>> I tried some bandwidth rates and i saw that target must be increas= ed if
>> the available bandwidth is <4mbps. 13ms is a good compromise fo= r that
>> situation.
>> Also, i removed the switch from my testbed.
>> Codel works amazingly well, congratulations for the job that has b= een
>> done!
>> I'll try to make more tests to ensure that it will be suitable= for our
>> needs; we are building a new wireless mesh network in Italy based = on a
>> totally new architecture and Codel could be a great improvement fo= r queue
>> management on the nodes.
>>
>> Thanks again for your courtesy!
>> Alessandro Bolletta
>
>
> Kathy,
>
> So in this case, there is another packet of buffering *under* the code= l
> queue in the HTB line discipline (which buffers one packet), plus what= ever
> additional buffering of there may be in the device driver (where the m= ileage
> varies).

Which exits at line rate, so it's not a huge issue timewise,
particularly in an age where cable modems are specced to run at gigE.

But the time the packet spends in HTB = *is* significant in terms of time, and it's not going into the computat= ion of the time in the queue.=A0

> So codel isn't actually dropping the head of the queue, but the se= cond (or
> further) packet back, in effect. =A0So the control law computation won= 't be
> quite right.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Jim

It certainly is feasible to produce a version of fq_codel that is lik= e
tbf or htb internally. Eric figured it would be a couple dozen lines
of code...

For htb that might be = the "best" solution, since it is a case we're unfortunately g= oing to be living with for quite a while.=A0

Then there is the time spent in the device driver; for example, John's = hack Lantiq DSL driver with it's (current) two packets of buffering.

Those packets trickle out at DSL line ra= te (slow), not the fast speed of 100Mb or 1G ethernet being transmitted to = a cable modem.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Jim




Actually it could be simpler in terms of interacting with the linux
scheduler than those alternatives as we're doing timestamping anyway, so with an explicit bandwidth limit it's straightforward to predict
when the next packet can be delivered at what re-scheduled time....

It would save an unmanaged packet outstanding, too. Well, hmm, that
would have to get looked at by the estimator...

Use cases:

1) ISPs artificially rate limit lines regardless
2) So do virtual service providers
3) our current need to reduce bandwidth to below the crappy device
next in line..

The last problem is so pervasive that I have a whole bunch of complex
htb scripts to do it right. It would be easier to have a rate limited
fq_codel (well, one that also does prioritization like pfifo_fast) and
less cpu intensive to move all that logic out of the combination of
fq_codel + htb and into one qdisc...

just a thought...

--
Dave T=E4ht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscrib= e.html
=A0

--047d7bdc8fd018dedb04d161df3e--