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: Wed, 07 Nov 2018 15:53:06 +0100 [thread overview] Message-ID: <87va59uegc.fsf@toke.dk> (raw) In-Reply-To: <10b644b6c7f436a892e3e9f4fd5e179d@codeaurora.org> 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
WARNING: multiple messages have this Message-ID (diff)
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: Wed, 07 Nov 2018 15:53:06 +0100 [thread overview] Message-ID: <87va59uegc.fsf@toke.dk> (raw) In-Reply-To: <10b644b6c7f436a892e3e9f4fd5e179d@codeaurora.org> 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2018-11-07 14:53 UTC|newest] Thread overview: 48+ 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 ` Rajkumar Manoharan 2018-10-20 11:05 ` [PATCH 1/6] mac80211: Add TXQ scheduling API Rajkumar Manoharan 2018-10-20 11:05 ` Rajkumar Manoharan 2018-11-09 12:00 ` Johannes Berg 2018-11-09 12:00 ` Johannes Berg 2018-11-09 12:39 ` Toke Høiland-Jørgensen 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 ` Rajkumar Manoharan 2018-10-20 11:05 ` [PATCH 3/6] mac80211: Add airtime accounting and scheduling to TXQs Rajkumar Manoharan 2018-10-20 11:05 ` Rajkumar Manoharan 2018-10-26 14:16 ` Toke Høiland-Jørgensen 2018-10-26 14:16 ` Toke Høiland-Jørgensen 2018-10-26 23:04 ` Rajkumar Manoharan 2018-10-26 23:04 ` Rajkumar Manoharan 2018-10-28 15:48 ` Toke Høiland-Jørgensen 2018-10-28 15:48 ` Toke Høiland-Jørgensen 2018-10-28 22:01 ` Rajkumar Manoharan 2018-10-28 22:01 ` Rajkumar Manoharan 2018-10-29 23:50 ` Rajkumar Manoharan 2018-10-29 23:50 ` Rajkumar Manoharan 2018-11-02 10:30 ` Toke Høiland-Jørgensen 2018-11-02 10:30 ` Toke Høiland-Jørgensen 2018-11-05 8:39 ` Rajkumar Manoharan 2018-11-05 8:39 ` Rajkumar Manoharan 2018-11-07 14:53 ` Toke Høiland-Jørgensen [this message] 2018-11-07 14:53 ` Toke Høiland-Jørgensen 2018-11-07 22:35 ` Rajkumar Manoharan 2018-11-07 22:35 ` Rajkumar Manoharan 2018-11-08 13:46 ` Toke Høiland-Jørgensen 2018-11-08 13:46 ` Toke Høiland-Jørgensen 2018-10-31 6:17 ` yiboz 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 ` Rajkumar Manoharan 2018-10-20 11:05 ` [PATCH 5/6] ath10k: migrate to mac80211 txq scheduling Rajkumar Manoharan 2018-10-20 11:05 ` Rajkumar Manoharan 2018-10-24 8:33 ` Kalle Valo 2018-10-24 8:33 ` Kalle Valo 2018-10-24 18:55 ` Rajkumar Manoharan 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-20 11:05 ` Rajkumar Manoharan 2018-10-24 8:35 ` Kalle Valo 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 2018-10-21 11:27 ` 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=87va59uegc.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.