Felix Fietkau <nbd@xxxxxxxx> writes: > On 2016-09-08 21:59, Toke Høiland-Jørgensen wrote: >> CoDel can be too aggressive if a station sends at a very low rate. This >> gets worse the more stations are present, as each station gets more >> bursty the longer the round-robin scheduling between stations takes. >> >> This is an attempt to dynamically adjust CoDel parameters per station. >> It takes a rather simple approach and uses a simple binary designation >> of a station as 'slow' if it has expected throughput less than eight >> Mbps (i.e. the lowest couple of rates). In this case, CoDel is set to be >> more lenient by adjusting its target to 50 ms and interval to 300 ms. >> There's a built-in hysteresis so a station cannot flip between slow and >> fast more than once every two seconds. >> >> In this version the check is performed every time a packet is enqueued >> to the intermediate queues; and the overhead of doing this is alleviated >> a bit by caching the result and by the above-mentioned hysteresis. It >> can probably be smarter about both when and how to do the scaling, but >> this seems to alleviate some of the starvation I've seen with very slow >> stations. > Since this is not dealing properly with firmware rate control anyway, > I'd suggest calling the update from rate_control_set_rates in order to > avoid putting more stuff into the tx hot path. Yeah, I wasn't expecting that to stay in the TX path, but was not familiar enough with minstrel to know where a good place would be. Thanks for the pointer. > You could add a separate code path to allow firmware rate control > devices to provide a hint at a convenient point in time. There's already a get_expected_throughput() driver hook; but no drivers seem to be using it? But I assume you mean a hook the other way, i.e. export a function where the driver can tell mac80211 "my expected throughput changed, please update"? -Toke
