Re: [PATCH 3/6] mac80211: Add airtime accounting and scheduling to TXQs

From: Rajkumar Manoharan <rmanohar@codeaurora.org>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
Subject: Re: [PATCH 3/6] mac80211: Add airtime accounting and scheduling to TXQs
Date: Fri, 26 Oct 2018 16:04:23 -0700	[thread overview]
Message-ID: <9c2b790132a9a89fecd7dd79dc67d891@codeaurora.org> (raw)
In-Reply-To: <8736ssbxp9.fsf@toke.dk>

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?

> 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

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k