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

[Jim Gettys <jg@freedesktop.org>]

[-- Attachment #1: Type: text/plain, Size: 3542 bytes --]

On Fri, Dec 21, 2012 at 1:57 PM, Dave Taht <dave.taht@gmail.com> 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.net> wrote:
> >>
> >> Hi everybody,
> >> Thanks so much for your useful help! I solved my problem by reproducing
> >> bottleneck through HTB queues.
> >> I tried some bandwidth rates and i saw that target must be increased if
> >> 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äht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
>
>
>

[-- Attachment #2: Type: text/html, Size: 4939 bytes --]