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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Fri, Oct 19, 2018 at 10:34 AM Ben Greear <[email protected]> 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
On 10/19/2018 11:25 AM, Steve deRosier wrote:
> On Fri, Oct 19, 2018 at 10:34 AM Ben Greear <[email protected]> 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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com
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
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
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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com
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