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

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Rajkumar Manoharan <rmanohar@codeaurora.org> writes:

> On 2018-11-02 03:30, Toke Høiland-Jørgensen wrote:
>> Rajkumar Manoharan <rmanohar@codeaurora.org> writes:
>> 
>>> On 2018-10-28 15:01, Rajkumar Manoharan wrote:
>>>> On 2018-10-28 08:48, Toke Høiland-Jørgensen wrote:
>>>>> Rajkumar Manoharan <rmanohar@codeaurora.org> writes:
>>>>> 
>>>>>> 
>>>>>> 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.
>>>> 
>>> Toke,
>>> 
>>>  From above results, different airtime for each station is reflecting 
>>> on
>>> output performance. Unfortunately I don't see such tput difference, 
>>> when
>>> the tx mode is fixed in push-only. Even low weight station is giving
>>> same
>>> performance. Are you also seeing the same behavior in your setup? 
>>> Could
>>> you please share your results?
>> 
>> Sorry, I've been travelling this week; I'll be back in the office next
>> week and can run some tests then. I may also have an idea for a
>> different algorithm that will work better in pull mode, but need to see
>> if it works at all first :)
>> 
> Wow... :)
>
> Meanwhile we did some more experiments with both modes. The experiment
> was done in open environment and fixed rate and UDP traffic ran for 60
> seconds.
>
> Seems like push mode not honoring the configured weight. Always the
> airtime was almost same whereas in pull-mode airtime is changing based
> on configured weight. Hence I would like to know your results.

Right, so I verified that the current version of the patch set still
works with ath9k. However, the ath10k card I have doesn't seem to
support peer stats, so I can't test ath10k. 

$ lspci | grep Qualcomm
03:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter

$ cat /sys/kernel/debug/ieee80211/phy1/ath10k/chip_id 
0x043202ff

$ cat /sys/kernel/debug/ieee80211/phy1/ath10k/wmi_services  | grep PEER
WMI_SERVICE_PEER_CACHING                 -
WMI_SERVICE_PEER_STATS                   -


Is there a way to force-enable airtime support, is this a hardware issue?

> 		sta1		sta2		sta3		sta4
> pull-mode	8s(205us)	18s(3.2ms)	8s(205us)	14s(410us)
> 		12s(256us)	12s(256us)	13s(256us)	12s(256us)
> 		14s(4ms)	13s(4ms)	14s(4ms)	13s(4ms)
>
> push-mode	15s(205us)	12s(3.2ms)	16s(205us)	12s(410us)
> 		15s(256us)	12s(256us)	16s(256us)	12s(256us)
> 		14s(4ms)	13s(4ms)	16s(4ms)	12s(4ms)

Right, so the pull-mode results are encouraging! *Something* is
happening, at least, even though the aggregate airtime doesn't quite
match the ratios of the configured weights.

Are you running the UDP generator on the AP itself, or on a separate
device, BTW? If it's on the AP, the userspace socket can get throttled,
which will interfere with results, so it's better to have it on a
separate device (connected via ethernet).

As for push-mode, could this be because of bad buffer management? I.e.,
because there's a lag between the time airtime is registered, and the
time that airtime usage is reported, the driver just pushes a whole
bunch of packets to the firmware when it gets the chance, which prevents
the scheduler from throttling properly. This could also explain the
better, but not quite perfect, results in pull mode, assuming that pull
mode results in better firmware buffer management which reduces, but
doesn't quite remove, the lag.

If this is indeed the reason, the queue limit patches should hopefully
be a solution. So guess we need to get those working as well :)

-Toke