[Codel] The next slice of cake

[Sebastian Moeller]

Hi Dave, hi Jonathan,

On Mar 21, 2015, at 17:09 , Dave Taht <dave.taht at gmail.com> wrote:

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

	I could be out to lunch here, as usual,;but I argue the byte limit should include the kernel overhead (could this be based on skb->truesize) as this is what cunts against real memory. My assumption here is that in normal operation we rarely/never get queues to fill up to the limit anyways (as tho would turn the queue into tail-drop effectively), but if we do we really need to account for the worst case (especially on home routers). What do you think?

Best Regards
	Sebastian

> 
> 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
> _______________________________________________
> Codel mailing list
> Codel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel