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

[Dave Taht <dave.taht@gmail.com>]

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.

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

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