I find myself torn by 3 things.

1) The number of huge wins in fixing wifi far outweigh what we have
thus far achieved, or not achieved, in cake.

2) Science - Cake is like wet paint! There knobs to fiddle, endless
tests to run, new ideas to try... measurements to take! papers to
write!

3) Engineering - I just want it to be *done*. It's been too long. It
was demonstrably faster than htb + fq_codel on weak hardware last
june, and handled GRO peeling, which were the two biggest "bugs" in
sqm I viewed we had.

In wearing these 3 hats, I would

3A) like to drop cake, personally, from something I needed to care about.
3B) But, can't, because the profusion of features need to be fully evaluated.
In this test series: http://snapon.cs.kau.se/~d/bcake_tests/ neither
cake or bcake were "better" than the existing codel in any measurable
way, and in most cases, worse. bcake did mildly better at a short
(10ms) RTT... which was interesting.

If you want to take apart this batch with "flent", looking for
enlightenment, also, please go ahead.

Were I to short circuit the science here, I'd rip out the sqrt cache
and fold back in mainline codel into cake. This would also have the
added benefit of also moving us back to 32bitland for various values
(tho "now" becomes a bit trickier) and hopefully improving cpu
efficiency a bit further (but this has to get done carefully unless
your head is good at 32 bit overflow math)

Next up, a series testing the fq portions...

If someone (else) would like to fork cake again and do the two things
above, I'd appreciate it.

3C) Most of the new statistics are pretty useless IMHO. Interesting,
but in the end I mostly care about drops and marks only.

3D) Don't have a use for the rate estimator either, and so far the
dual queue idea has not materialized. I understand how it might be
done now - using the 8 way set associative thing per DEST hash, but I
don't really see the benefit of that vs just using a DEST hash in the
first place.

3E) Want cake to run as fast as possible on cheap hardware and be a
demonstrable win over htb + fq_codel - and upstream it and be done
with it.

3F) At the moment I'm favoring peeling at the current quantum rather
than anything more elaborate.

3G) really want the thing to work correctly down to 64k and up to at
least a gbit.
which needs testing... but probably after we pick a codel....

2A) As a science vehicle, there are many other things we could be
trying in cake, and I happen to like the idea of the (currently sort)
cache in for example, trying a faster curve at startup - or, as in the
ns2 code - a harder curve at say count + 128 or even earlier, as the
speed up in drops gets pretty tiny even at count + 16. (see attached)

(it doesn't make much sense to calculate the sqrt at run time - you
can just calculate the constants elsewhere and plug them in, btw.
attached is a teeny proggie that does that an also explores a harder
initial curve (you'd jump count up to where it matched the curve when
you reverted to the invsqrt calculation) - and no, I haven't tried
plugging this in either... DANGER! Wet Paint!

I also like keeping all the core values 64 bits, from a science perspective.

There are also things like reducing the number of flows, and
exercising the 8 way associative cache more - to say 256, 128, or even
32? Or relative to the bandwidth... or target setting...

and I do keep wishing we could at the very least resolve the target >
mtu issue. std codel turns off with a single mtu outstanding. That
arguably should have been all that was needed...

and then there's ecn...

1A) Boy do we have major problems with wifi, and major gains to be had
1B) All the new platforms have bugs eveyerhwer, including in the
ethernet drivers

0)

So I guess it does come down to - what are the "musts" for cake before
it goes upstream? How much more work is required, by everybody, on
every topic, til that happens? Can we just fork off what is known to
work reasonably well, and let the rest evolve separately in a cake2?
(cleaning up the api in the process?) Is it still "cake" if we do
that?

Because, damn it, 2016 is going to be the year of WiFi.


Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi