On 2018-10-26 07:16, Toke Høiland-Jørgensen wrote:
Rajkumar Manoharan <rmanohar@xxxxxxxxxxxxxx> writes:
From: Toke Høiland-Jørgensen <toke@xxxxxxx>
[...]
u8 max_nan_de_entries;
u8 tx_sk_pacing_shift;
+ u32 airtime_weight;
};
This doesn't make sense. Airtime weights can be set by userspace, so
even if a driver sets another default it is not guaranteed to be
honoured. So what's the point?
The reason for driver specific default is to avoid performance impact
in ath10k when the user is using vanilla ath10k with default airtime.
As I mentioned earlier, mac80211 default (256us) is too low for 11ac
devices
especially with driver is bursting aggregation.
Yes. I do understand the user can change airtime at anytime but It must
be
noted that different airtime weight will result in different throughput.
IMHO the defaults should not impact current benchmark. Otherwise it will
be
alarmed as regression later. isn't it?
So since we're rotating the queue on every call to the function, I'm
wondering if this actually succeeds in throttling the slow station's
airtime usage enough to achieve fairness? So I'll ask again: Did you
test the fairness performance, and how?
We are collecting data of mixed clients (11ac, 11n and legacy) keeping
them
at same distance and different distance. So that lower rate clients will
interfere higher MCS rate station. Also configuring different airtime
weight
for each stations so that throttling low rate clients more should help
higher
performing(better MCS) clients.
By allowing different airtime for each stations, the user can control
guest
network over primary network. Also It helped to improve performance of
preferred
station and algo. to control station is given to cloud or user
application.
As of now, We are testing with 4 11ac clients of same distance. And
collecting
the performance data in multiple iteration. Below are current data of
station's performance (Mbps) against airtime weight.
airtime station1(%airtime) station2 station3 station4
(Mbps)
No ATF 182 168 166 169
4ms 170 (100%) 164 (100%) 185 (100%) 175 (100%)
4ms 277 (70%) 115 (10%) 103 (10%) 105 (10%)
4ms 223 (40%) 214 (40%) 109 (10%) 94 (10%)
4ms 337 (90%) 182 (8%) 23 (1%) 30 (1%)
STA1(11ac) STA2 (11n) STA3(11a)
========== ========== =========
No ATF 225 166 3.5
ATF (4ms) 234 151 3.5
Also, taking a step back:
With this, we're doing lots of work to make sure that the hardware's
round-robin scheduling queue lines up with mac80211; so if we do this
anyway, why can't we just control the order directly from mac80211
(which is what we do with the other next_txq() API)?
The only way to enforce mac80211 ordering in ath10k is to disable pull
mode in firmware and always operates in push mode similar to ath9k.
-Rajkumar
