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 <[email protected]> wrote: > > > On Wed, Mar 18, 2015 at 8:20 AM, Jonathan Morton <[email protected]> > wrote: >> >> >> > On 18 Mar, 2015, at 17:10, Kathleen Nichols <[email protected]> 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 >> [email protected] >> 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 [email protected] https://lists.bufferbloat.net/listinfo/codel
