cake: changing bandwidth on the rate limiter dynamically

cake: changing bandwidth on the rate limiter dynamically

[Dave Taht]

One of the nice things that the gargoyle-qos system does is that it
attempts to measure the bandwidth actively and modify the actual
bandwidth in the rate limiter to suit.

It does this with some very hairy code into the htb/hfsc subsystem,
and measuring ping to either a server elsewhere or short ttl udp +
icmp returns.... (can't remember which)

dealing with the measurements correctly when traffic is possibly
bottlenecking in both directions I think it fails on. As does
streamboost.

Now, it turns out that cake makes altering the bandwidth really easy,
you can just change it from the command line.

http://pastebin.com/Jr9s6EBW

I am pretty sure changing it is currently pretty damaging to stuff in
flight (don't remember), but
it needent be.

I think dynamically sensing the underlying bandwidth would be a great
boon, rather than having to set it so explicitly, and perhaps by
sensing some other parameters like ack clocks or overall traffic flow
at a depth that bpf could resolve, might be a valid approach.


-- 
Dave Täht

http://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

Re: cake: changing bandwidth on the rate limiter dynamically

[Jonathan Morton]

> On 12 Dec, 2014, at 17:52, Dave Taht <dave.taht@gmail.com> wrote:
> 
> Now, it turns out that cake makes altering the bandwidth really easy,
> you can just change it from the command line.
> 
> http://pastebin.com/Jr9s6EBW
> 
> I am pretty sure changing it is currently pretty damaging to stuff in
> flight (don't remember), but it needent be.

I don’t think it is harmful.  All that happens is that the packet issue deadlines start to be advanced at a different rate with each packet transmitted.  A change in the rate by that mechanism doesn’t cause any packet flushing or other trouble.

The flow-discrimination mode and the diffserv mode can also be changed in the same way, but this is more disruptive; it may at least result in some packets arriving out of order within flows, if not also some spurious drops.  But the network can tolerate that happening occasionally.

 - Jonathan Morton

Re: cake: changing bandwidth on the rate limiter dynamically

[Dave Taht]

On Fri, Dec 12, 2014 at 7:59 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
>> On 12 Dec, 2014, at 17:52, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> Now, it turns out that cake makes altering the bandwidth really easy,
>> you can just change it from the command line.
>>
>> http://pastebin.com/Jr9s6EBW
>>
>> I am pretty sure changing it is currently pretty damaging to stuff in
>> flight (don't remember), but it needent be.
>
> I don’t think it is harmful.  All that happens is that the packet issue deadlines start to be advanced at a different rate with each packet transmitted.  A change in the rate by that mechanism doesn’t cause any packet flushing or other trouble.
>
> The flow-discrimination mode and the diffserv mode can also be changed in the same way, but this is more disruptive; it may at least result in some packets arriving out of order within flows, if not also some spurious drops.  But the network can tolerate that happening occasionally.

Good to know.

While fiddling with the idea a bit, I found that you can add a
bandwidth limit to cake on the fly, but once added you cant remove it
with the syntax at hand.

I plan to start up a new debloat-testing tree after the new year,
containing bits of cake, and wireless-next,
where it might be easier to fiddle. I do plan to stick to x86_64 for a
while on that until something lands that is solid and useful on an
embedded system.

(It is long past time I shelled out some cash for github (as storing a
kernel there would wipe out my disk space allocation), and will
probably store the new tree there, unless someone objects)

... in the meantime, my current patchset for cake, cake variants, and
for all the other qdisc work under test is here:

http://snapon.lab.bufferbloat.net/~d/codel_patches/

It applies against net-next, and linux-3.14. The *.deb files are a
kernel build for the latest ubuntu release.

And I did do a build of chaos calmer as a test containing a slightly
older version of that patch set

http://snapon.lab.bufferbloat.net/~cero3/chaos_calmer/ar71xx/

Which I have been running for nearly 2 weeks now on a test wndr 4300 box.

Sadly, although cake works great, it seems to have about the same cpu
limitations as htb+fq_codel, so further work on the ingress path seems
needed on these low end cpus (or we need to give up and just find
faster hardware).

>  - Jonathan Morton
>



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

Re: cake: changing bandwidth on the rate limiter dynamically

[Jonathan Morton]

> On 12 Dec, 2014, at 19:44, Dave Taht <dave.taht@gmail.com> wrote:
> 
> While fiddling with the idea a bit, I found that you can add a
> bandwidth limit to cake on the fly, but once added you cant remove it
> with the syntax at hand.

Yes you can:

# tc qdisc change dev ifb0 handle 2: cake unlimited

 - Jonathan Morton

Re: cake: changing bandwidth on the rate limiter dynamically

[Dave Taht]

On Fri, Dec 12, 2014 at 6:55 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 12 Dec, 2014, at 19:44, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> While fiddling with the idea a bit, I found that you can add a
>> bandwidth limit to cake on the fly, but once added you cant remove it
>> with the syntax at hand.
>
> Yes you can:
>
> # tc qdisc change dev ifb0 handle 2: cake unlimited

I guess all that is needed is a marie antoinette mode, then, huh?

>  - Jonathan Morton
>



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

Re: cake: changing bandwidth on the rate limiter dynamically

[Jonathan Morton]

> On 13 Dec, 2014, at 05:57, Dave Taht <dave.taht@gmail.com> wrote:
> 
> I guess all that is needed is a marie antoinette mode, then, huh?

For that, we would need to have something called “bread” for cake to be an alternative to.  But then again, what was the French for bread again?  ;-)

 - Jonathan Morton