* Where to report mpdus tx vs failed? @ 2018-10-19 17:34 Ben Greear 2018-10-19 18:25 ` Steve deRosier 0 siblings, 1 reply; 7+ messages in thread From: Ben Greear @ 2018-10-19 17:34 UTC (permalink / raw) To: linux-wireless While debugging rate-ctrl in ath10k, I found the amount of mpdus transmitted vs failed ratio useful. Probably more useful than retries since retries could count an attempt at 80Mhz followed by HW trying a 40Mhz rate (afaik). Is there a good way to report this up the stack in a useful manner? I currently only get this stat for the first frame in an transmitted ampdu. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Where to report mpdus tx vs failed? 2018-10-19 17:34 Where to report mpdus tx vs failed? Ben Greear @ 2018-10-19 18:25 ` Steve deRosier 2018-10-19 18:32 ` Ben Greear 0 siblings, 1 reply; 7+ messages in thread From: Steve deRosier @ 2018-10-19 18:25 UTC (permalink / raw) To: Ben Greear; +Cc: linux-wireless On Fri, Oct 19, 2018 at 10:34 AM Ben Greear <greearb@candelatech.com> wrote: > > While debugging rate-ctrl in ath10k, I found the amount of mpdus transmitted vs failed > ratio useful. Probably more useful than retries since retries could count an attempt at > 80Mhz followed by HW trying a 40Mhz rate (afaik). > > Is there a good way to report this up the stack in a useful manner? I currently only > get this stat for the first frame in an transmitted ampdu. > debugfs? Is it useful for someone working on it, like a sysadmin or kernel programmer? Or is it useful for programs to know? In the first case I'd say debugfs, in the second case I'd suggest it goes in some tx stats structure that is reported by netlink. Also, is it something that is given by (or should be given by) all drivers, or is it very driver-specific? - Steve ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Where to report mpdus tx vs failed? 2018-10-19 18:25 ` Steve deRosier @ 2018-10-19 18:32 ` Ben Greear 2018-10-22 12:06 ` Johannes Berg 0 siblings, 1 reply; 7+ messages in thread From: Ben Greear @ 2018-10-19 18:32 UTC (permalink / raw) To: Steve deRosier; +Cc: linux-wireless On 10/19/2018 11:25 AM, Steve deRosier wrote: > On Fri, Oct 19, 2018 at 10:34 AM Ben Greear <greearb@candelatech.com> wrote: >> >> While debugging rate-ctrl in ath10k, I found the amount of mpdus transmitted vs failed >> ratio useful. Probably more useful than retries since retries could count an attempt at >> 80Mhz followed by HW trying a 40Mhz rate (afaik). >> >> Is there a good way to report this up the stack in a useful manner? I currently only >> get this stat for the first frame in an transmitted ampdu. >> > > debugfs? Is it useful for someone working on it, like a sysadmin or > kernel programmer? Or is it useful for programs to know? In the > first case I'd say debugfs, in the second case I'd suggest it goes in > some tx stats structure that is reported by netlink. > > Also, is it something that is given by (or should be given by) all > drivers, or is it very driver-specific? I was hoping I could fit it into some existing stat. It is sort of like retries, so that will be my first attempt. By investigating an RF sniff, I notice the 9880 ath10k (with my fw and driver, at least), will retransmit about 30% of the frames when running at least one of my test cases (small udp frame transmit to AP that can only do about mcs5 or mcs7 reliably at 3x3 nss). I'd like to report this stat in my wifi test tool if nothing else, but likely other people would make use of it as well. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Where to report mpdus tx vs failed? 2018-10-19 18:32 ` Ben Greear @ 2018-10-22 12:06 ` Johannes Berg 2018-10-22 12:07 ` Johannes Berg 0 siblings, 1 reply; 7+ messages in thread From: Johannes Berg @ 2018-10-22 12:06 UTC (permalink / raw) To: Ben Greear, Steve deRosier; +Cc: linux-wireless On Fri, 2018-10-19 at 11:32 -0700, Ben Greear wrote: > > I was hoping I could fit it into some existing stat. It is sort of like > retries, so that will be my first attempt. > > By investigating an RF sniff, I notice the 9880 ath10k (with my fw > and driver, at least), will retransmit about 30% of the frames when running > at least one of my test cases (small udp frame transmit to AP that can only do about mcs5 or mcs7 > reliably at 3x3 nss). > > I'd like to report this stat in my wifi test tool if nothing else, but > likely other people would make use of it as well. We have NL80211_STA_INFO_TX_RETRIES, shouldn't you be able to capture it there? johannes ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Where to report mpdus tx vs failed? 2018-10-22 12:06 ` Johannes Berg @ 2018-10-22 12:07 ` Johannes Berg 2018-10-22 17:16 ` Ben Greear 0 siblings, 1 reply; 7+ messages in thread From: Johannes Berg @ 2018-10-22 12:07 UTC (permalink / raw) To: Ben Greear, Steve deRosier; +Cc: linux-wireless On Mon, 2018-10-22 at 14:06 +0200, Johannes Berg wrote: > On Fri, 2018-10-19 at 11:32 -0700, Ben Greear wrote: > > > > I was hoping I could fit it into some existing stat. It is sort of like > > retries, so that will be my first attempt. > > > > By investigating an RF sniff, I notice the 9880 ath10k (with my fw > > and driver, at least), will retransmit about 30% of the frames when running > > at least one of my test cases (small udp frame transmit to AP that can only do about mcs5 or mcs7 > > reliably at 3x3 nss). > > > > I'd like to report this stat in my wifi test tool if nothing else, but > > likely other people would make use of it as well. > > > We have NL80211_STA_INFO_TX_RETRIES, shouldn't you be able to capture it > there? Or, per TID, NL80211_TID_STATS_TX_MSDU_RETRIES johannes ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Where to report mpdus tx vs failed? 2018-10-22 12:07 ` Johannes Berg @ 2018-10-22 17:16 ` Ben Greear 2018-10-23 9:36 ` Johannes Berg 0 siblings, 1 reply; 7+ messages in thread From: Ben Greear @ 2018-10-22 17:16 UTC (permalink / raw) To: Johannes Berg, Steve deRosier; +Cc: linux-wireless On 10/22/2018 05:07 AM, Johannes Berg wrote: > On Mon, 2018-10-22 at 14:06 +0200, Johannes Berg wrote: >> On Fri, 2018-10-19 at 11:32 -0700, Ben Greear wrote: >>> >>> I was hoping I could fit it into some existing stat. It is sort of like >>> retries, so that will be my first attempt. >>> >>> By investigating an RF sniff, I notice the 9880 ath10k (with my fw >>> and driver, at least), will retransmit about 30% of the frames when running >>> at least one of my test cases (small udp frame transmit to AP that can only do about mcs5 or mcs7 >>> reliably at 3x3 nss). >>> >>> I'd like to report this stat in my wifi test tool if nothing else, but >>> likely other people would make use of it as well. >> >> >> We have NL80211_STA_INFO_TX_RETRIES, shouldn't you be able to capture it >> there? > > Or, per TID, NL80211_TID_STATS_TX_MSDU_RETRIES I added this code (rate is struct ieee80211_tx_rate) if (tx_done->mpdus_failed) { /* Maybe there is a better way to report this tried vs failed stat up the stack? */ rate->count = tx_done->mpdus_failed + 1; } else { rate->count = 1; } I think this is mostly providing useful info up the stack and we are trying to verify the counts against a packet sniff today. The driver is only reporting this number for the first packet in the ampdu chain, so all retries are counted against the first frame (the rest will have mpdus_failed == 0 regardless of how many retries they have). And, on total retry failure, packets should be reported up the stack as tx-no-ack, so I think that is working OK too. I guess mac80211 could use this tx-status to report per-tid if it cared to. I don't see any other way to pass such tx failure details up the stack to mac80211. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Where to report mpdus tx vs failed? 2018-10-22 17:16 ` Ben Greear @ 2018-10-23 9:36 ` Johannes Berg 0 siblings, 0 replies; 7+ messages in thread From: Johannes Berg @ 2018-10-23 9:36 UTC (permalink / raw) To: Ben Greear, Steve deRosier; +Cc: linux-wireless On Mon, 2018-10-22 at 10:16 -0700, Ben Greear wrote: > > > We have NL80211_STA_INFO_TX_RETRIES, shouldn't you be able to capture it > > > there? > > > > Or, per TID, NL80211_TID_STATS_TX_MSDU_RETRIES > > I added this code (rate is struct ieee80211_tx_rate) > > if (tx_done->mpdus_failed) { > /* Maybe there is a better way to report this tried vs failed stat up the stack? */ > rate->count = tx_done->mpdus_failed + 1; > } > else { > rate->count = 1; > } Ah, you were asking about mac80211? I guess if you have the statistic, you can override it in get_sta_stats() instead of trying to make mac80211 keep them based on the rate (control) information. johannes ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-10-23 9:36 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-10-19 17:34 Where to report mpdus tx vs failed? Ben Greear 2018-10-19 18:25 ` Steve deRosier 2018-10-19 18:32 ` Ben Greear 2018-10-22 12:06 ` Johannes Berg 2018-10-22 12:07 ` Johannes Berg 2018-10-22 17:16 ` Ben Greear 2018-10-23 9:36 ` Johannes Berg
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.