On 2018-10-28 08:48, Toke Høiland-Jørgensen wrote:
Rajkumar Manoharan <rmanohar@xxxxxxxxxxxxxx> writes:
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?
My point is that if the user has to know the implementation-specific
limitations of each driver before setting a weight, then it's not a
particularly friendly API. I think we should be able to do better than
that...
Hmm.. I was trying to balance throughput vs CPU usage. Keeping lower
threshold is causing more lock contention and impacting throughput.
I thought of configuring default airtime_weight from hostapd for
legacy, 11n and 11ac stations.
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%)
So this looks like it's doing *something*, but not like it's succeeding
in achieving the set percentages. Did you check if the actual airtime
values (in debugfs) corresponds to the configured weights?
No. Will check that.
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.
And I assume that is not too likely to happen, or? What is the benefit
of pull mode at the firmware level?
Pull mode mainly required to support MU-MIMO. IMHO both MUMIMO & ATF can
not
co-exist unless both are implemented at host driver. Fixing tx mode in
ath10k
needs firmware reload. By introducing modparam, pull-mode can be
disabled.
-Rajkumar
