Pete Heist <[email protected]> writes: >> On Nov 12, 2017, at 6:00 PM, [email protected] wrote: >> >> I sometimes think we should establish an organization, with a board of >> directors, a bank account, etc, but aside >> from grant money, donated computers and computer time, and all the >> massive efforts of all the volunteers, that's most of the donations >> we've ever got, and it would be, at least, 800 bucks to start a >> non-profit, + an accountant to "do right". >> >> Any and all thoughts as to how to do better are welcomed. >> >> We could have a bake sale for cake, to get it mainlined. > > Has there been any thought towards monetizing some portion of the bufferbloat > project to help pay for it? Here are a couple of ideas:
I'm going to skip commenting in the hope that others chime in first. > By the way, what or how much is needed to get Cake mainlined? I'd like us to give it a go when net-next reopens in two weeks, we'd then have 6 weeks or so to get it right. We need: * Someone to do the heavy lifting. Which I suspect would be me. * Someones with various hardware platforms that current kernels can be run on. qemu? * I'd like to see the ack filtering work get tested on lede at low bandwidths on dsl especially. * A whole lotta tests at various RTTs Blockers: * Ripping out all the backward compatability cruft for submission to mainline and following netdev formatting conventions for comments and indentation. I'd like any new features in the backport to get backported, though (sigh), as lede looks to be shipping a 4.9 based kernel. * tc-cake man page needs to be updated. * tc-adv related code updated to latest iproute2 * There is some work going on here to add ack filtering to cake, which looks VERY promising: https://github.com/dtaht/sch_cake/pull/63 I'm going to add something like this to netem also. It may be that merely leveraging the hash would be enough in cake's case. * Testing against the net-next kernel on x86, x86_64, arm, mips, and aarch architectures. (I just got bit by not testing 32 bit arches, sigh) Non-Blockers: * I don't believe in cobalt, or rather, I won't believe in it until we have data at many RTTs. That said, what I'd propose would be a monolithic cobalt.h file rather than codel5.h. The netns stuff will make simulating RTTs and bandwidths much easier.... * I think the fq_codel batch drop facility is better than what cake uses in case of floods. Partially due to the need to handle backports the mechanism fq_codel uses is hard to use - but going mainline we could add this. * The autorate_ingress code should be marked experimental. I keep hoping it can be improved by better looking for "smoothness" inbound, but algorithms escape me. This doesn't bother me much, as tcp continues to be improved over the past 50 years, perhaps we can find ways to improve this with more users. * It is possible to tune the quantum and peeling functions to not peel to the extent they do. Particularly there is usually no need (aside from wanting accurate statistics) to peel below 1500 bytes (except perhaps with the new ack filter mode). We experimented a lot with this in the early days but could never come to a resolution. * I don't have any use for precidence mode and would like to remove it. _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
