I have largely been focused on make-wifi-fast until the last week, only doing a code review on cake over the last few days and submitting a few patches thus far.
I have sometimes been frustrated enough on the squash/wash issue to want to fork cake to "just do it", because RFC compliance actually mandates that the traffic be re-marked appropriately upon transiting a domain, and seeing CS1 enter my network from comcast really messes up if it is passed directly through to wifi. It is far, far better to squash on ingress, and to do it without a tc filter. In other patches: https://github.com/dtaht/sch_cake/pull/42 constifies things. (compile tested only, btw) And: I was not aware of this "feature": https://github.com/dtaht/sch_cake/issues/41 until yesterday and it needs testing against real traffic, on real RTTs. I think a lot of latency sensitive (and marked thus) traffic is now pretty bursty (videoconferencing in particular, as well as anything transiting a wifi hop beforehand) and (IMHO) the literature on short queues is now invalid and out of date for all but voice traffic. (that said, I'm willing to test first) ... stats keeping seems broken: https://github.com/dtaht/sch_cake/issues/43 I have always been allergic to all the stats in the first place. Keeping inaccurate stats is worse than no stats at all. ... I will gladly re-roll a patch for squashing. ... I would really like cake reviewed for suitability for mainlining before it becomes part of lede's next release. In particular the cobalt.*c* include has gotta go. ... I've done a bit of profiling on it, basically cpu-wise it eats about the same as htb+fq-codel does. _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
