Hi Felix, On Fri, Mar 1, 2013 at 3:59 PM, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: > On 2013-03-01 11:22 AM, Adrian Chadd wrote: >> 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. > Even with client airtime use, I still don't see how tx scheduling and > rate control belong together. In my opinion, the rate selection should > not be based on client airtime usage or the current load, as it can > optimize for throughput/airtime ratio without it. > Algorithm folks and Engineers had spent considerable time on ath9k rate control. Wouldn't be a great idea to remove it completely, We can have it optional. With lot of throughput tests ran over internally and with the test team verification, it wouldn't be fair to throw it away. -- thanks, shafi -- 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
