[Cake] cake byte limits too high by 10x

[Dave Taht]

On Fri, May 29, 2015 at 6:02 AM, Jonathan Morton <chromatix99 at gmail.com> wrote:
>> > What wifi needs is a bit different:
>> >
>> > (hosts/aggregates?) -> (shapers/minstrel?) -> priority -> flows ->
>> > signalling -> queues
>
>> Yep.
>
>> I don't see a huge need for "shaping" on wifi. I do see a huge need - as a
>> starting point - an airtime fair per station queue that is aggregation
>> aware, and slightly higher up, something that is aware of the overall
>> workload on the AP.
>
> Which is basically what I'm thinking of. "Airtime fair" is also known as
> "proportional fair". You need to know the data rate to each station for
> that.
>
> But knowing the data rate via minstrel, and the average expected time
> between transit opportunities to each station (which could probably be
> calculated rather than measured), would allow inferring certain things that
> I currently do using the shaper in cake, such as the appropriate size for
> the aggregate, and the amount of bandwidth that we can allow priority in.
> The only reason I can't reliably do that in cake with the shaper disabled is
> because I can't sense the hardware link rate, which is exactly what minstrel
> is in charge of.
>
> Incidentally, I suspect that aggregates of equal temporal length are
> valuable for multi station MIMO.
>
> It's also pretty obvious that selective link layer acks need to be acted on,
> and aggregates reformed for each transmit opportunity, whether a retry or
> not. I'm very disappointed to hear that those things often aren't already
> done, but it's probably a consequence of leaving that functionality to the
> hardware vendors so far. It's even possible that the current mess of binary
> blobs is a consequence of the weak support for aggregation in the kernel.

Hardware retry was very commonly used with very little control. So far
as I know the ath9k driver is now nearly pure software retry, with
very few smarts about it, but the infrastructure is there.

Reforming aggregates (and also giving up) is something that you have,
like 10us (don't quote me, relevant spec not at hand) to do. Even in a
double buffered scenario, older hardware would have trouble doing that
much work in that much time - and of course, nobody "got" how
important it was to do aggregates better in the multi-station
environment until recently.

some hardware offloads aggregation entirely (iwl). And I've been
meaning to check into the mwl driver stack since that is a new chipset
I don't grok yet... and there are a few other new candidates.....

> Probably not so much raw code (which autocorrected to coffee TWICE) can be
> reused from cake, not least due to simply operating at a different layer of
> the stack, but I think a lot of the conceptual advances can.

while I would like cake to one day stablize, it seems to be a good
vehicle to experiment in also, at least for a while.
;). It is (to me at least, at the moment) more important that the
ideas get thrashed out - despite the pent up demand for a better
shaper elsewhere.

Still, when (if) more resources arrive for make-wifi-fast, it will
make sense to produce a wifi "ap" std qdisc that interacts with
whatever ends up in mac80211, properly to give the two tiers of
per-station fairness and per flow "breakup" on a per station basis -
(I lean not towards calling it fq, I tend to think of it as "better
packing into an aggregate") - and freezing cake.

There are other issues up and down the stack on all sides.

> - Jonathan Morton



-- 
Dave Täht
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast