Rajkumar Manoharan <rmanohar@xxxxxxxxxxxxxx> writes: > On 2018-11-02 03:30, Toke Høiland-Jørgensen wrote: >> Rajkumar Manoharan <rmanohar@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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
