[Codel] The next slice of cake

[Dave Taht]

In terms of a cake feature request...

fq_codel has a maximum number of packets limit, which is set very
large (10000) to accommodate 10GigE. It is arbitrarily patched down in
openwrt (1000), and reduced still further by the sqm-scripts (also
arbitrarily), to reduce the impact of a packet flood on machines with
very little memory.

I would like cake to have a byte limit instead. Now, per packet
overhead in linux is very high, something like 256 extra bytes per
packet (4x1 vs the smallest size). However, a packet limit can be much
harder on memory than that - overhead be as large as 64k per "packet"
on TSO/GSO enabled systems, (dynamic range of 1x1000!), vs using a
byte limit which would only have issues with lots of small packets.

cake's bandwidth parameter can easily set a desirable max byte limit
at (say) 2 or 4x the BDP, and key off of that and not bother to track
a per packet limit.

It would be nice for cake (without shaping enabled) to be about to
automatically sense the actual interface rate and size this outer
limit appropriately, but I don't think mechanisms exist to do that.


On Wed, Mar 18, 2015 at 2:20 PM, Dave Taht <dave.taht at gmail.com> wrote:
>
>
> On Wed, Mar 18, 2015 at 8:20 AM, Jonathan Morton <chromatix99 at gmail.com>
> wrote:
>>
>>
>> > On 18 Mar, 2015, at 17:10, Kathleen Nichols <nichols at pollere.com> wrote:
>> >
>> > How are you relating target delay to bandwidth?
>>
>> Essentially, I use 5ms as a minimum, and increase it if necessary to
>> accommodate a couple of MTU-sized packets at the shaping rate.  This keeps
>> things nicely under control at low bandwidths, and I find that cake remains
>> useful and usable even at 64Kbps (without making even the usual adjustments
>> to host or link configuration for such low speeds).
>
>
> In the cake2 (or maybe it was the unpublished cake3) version, I had a
> lighter weight version of the codel algorithm, that did not have a target
> parameter at all. Instead it just took the interval parameter and shifted it
> right 4 (yielding a target of 6.xms from an interval of 100ms)
>
> This saves on a memory access (and storage per queue!) , and I felt that any
> differences in behavior would be unnoticeable. And they were. This is also
> above the bound for cable-modem media access that greg white (rightly or
> wrongly) believed existed. So I have no problem in eliminating "target"
> entirely.
>
> Cake (without bandwidth shaping engaged) uses more cpu than fq_codel did and
> this was one of many optimizations I'd attempted (or successfully added).
> Cake with shaping is a bit less cpu than sqm-scripts htb + fq_codel +
> filters.
>
> It also looked like cake could be poured into gates, with a bit more
> research, and testing.
>
>>
>> I can do this in cake because the shaping rate is known, whereas the pure
>> codel and fq_codel qdiscs do not have reliable link-speed information.
>
>
> As for this bit, we seemed to need to account for a MTU's worth of data at
> the lower speeds, and I did not explore what fiddling with the interval and
> auto-calc-ing the target did at these speeds, as yet.
>
>>
>> - Jonathan Morton
>>
>> _______________________________________________
>> Codel mailing list
>> Codel at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/codel
>
>
>
>
> --
> Dave Täht
> Let's make wifi fast, less jittery and reliable again!
>
> https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb