On 1 March 2013 02:14, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: >> Having access to schedule which peer and how much to send to each peer >> would be nice. Stuff like "peer X only can have up to x ms in this WME >> class this round", so you don't have a busy, close peer monopolising >> the air. It also means you can start doing smart things with far away >> peers who retransmit a lot - they're likely tying up a lot of airtime. >> >> None of this is new. It's just, you know, new to open source. :-) > In my opinion this doesn't really belong into a rate control module. > There should be a tx scheduling API to take care of this. Before I > implement something like this, I plan on exposing all per-station driver > queues to mac80211. This is necessary for a few other things anyway, > e.g. unifying software aggregation logic and fixing its buffer management. Sure, but then some more clever tricks end up being difficult to implement. For example, knowing if a client is tying up too much airtime at the given rate and whether to back them off for a bit. Or to use smaller aggregation limits for certain clients because your'e trying to be "fairer" when trying to keep latency low. That kind of thing. I think "rate control" should likely be expanded to "tx scheduling" as a whole, rather than sitting as a separate thing that just selects the rate for a node who has already been chosen to transmit. Adrian -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
