From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Rajkumar Manoharan <rmanohar@codeaurora.org>
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
Subject: Re: [PATCH 3/6] mac80211: Add airtime accounting and scheduling to TXQs
Date: Sun, 28 Oct 2018 16:48:09 +0100 [thread overview]
Message-ID: <87woq2843q.fsf@toke.dk> (raw)
In-Reply-To: <9c2b790132a9a89fecd7dd79dc67d891@codeaurora.org>
Rajkumar Manoharan <rmanohar@codeaurora.org> writes:
> On 2018-10-26 07:16, Toke Høiland-Jørgensen wrote:
>> Rajkumar Manoharan <rmanohar@codeaurora.org> writes:
>>
>>> From: Toke Høiland-Jørgensen <toke@toke.dk>
> [...]
>>> 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?
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...
>> 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%)
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?
>
> STA1(11ac) STA2 (11n) STA3(11a)
> ========== ========== =========
>
> No ATF 225 166 3.5
>
> ATF (4ms) 234 151 3.5
This also shows like ATF has no effect?
>> 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.
And I assume that is not too likely to happen, or? What is the benefit
of pull mode at the firmware level?
-Toke
next prev parent reply other threads:[~2018-10-28 15:48 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-20 11:05 [PATCH 0/6] Move TXQ scheduling and airtime fairness into mac80211 Rajkumar Manoharan
2018-10-20 11:05 ` [PATCH 1/6] mac80211: Add TXQ scheduling API Rajkumar Manoharan
2018-11-09 12:00 ` Johannes Berg
2018-11-09 12:39 ` Toke Høiland-Jørgensen
2018-10-20 11:05 ` [PATCH 2/6] cfg80211: Add airtime statistics and settings Rajkumar Manoharan
2018-10-20 11:05 ` [PATCH 3/6] mac80211: Add airtime accounting and scheduling to TXQs Rajkumar Manoharan
2018-10-26 14:16 ` Toke Høiland-Jørgensen
2018-10-26 23:04 ` Rajkumar Manoharan
2018-10-28 15:48 ` Toke Høiland-Jørgensen [this message]
2018-10-28 22:01 ` Rajkumar Manoharan
2018-10-29 23:50 ` Rajkumar Manoharan
2018-11-02 10:30 ` Toke Høiland-Jørgensen
2018-11-05 8:39 ` Rajkumar Manoharan
2018-11-07 14:53 ` Toke Høiland-Jørgensen
2018-11-07 22:35 ` Rajkumar Manoharan
2018-11-08 13:46 ` Toke Høiland-Jørgensen
2018-10-31 6:17 ` yiboz
2018-10-20 11:05 ` [PATCH 4/6] ath9k: Switch to mac80211 TXQ scheduling and airtime APIs Rajkumar Manoharan
2018-10-20 11:05 ` [PATCH 5/6] ath10k: migrate to mac80211 txq scheduling Rajkumar Manoharan
2018-10-24 8:33 ` Kalle Valo
2018-10-24 18:55 ` Rajkumar Manoharan
2018-10-20 11:05 ` [PATCH 6/6] ath10k: reporting estimated tx airtime for fairness Rajkumar Manoharan
2018-10-24 8:35 ` Kalle Valo
2018-10-21 11:27 ` [PATCH 0/6] Move TXQ scheduling and airtime fairness into mac80211 Toke Høiland-Jørgensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87woq2843q.fsf@toke.dk \
--to=toke@toke.dk \
--cc=ath10k@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=rmanohar@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).