ath10k fw_stats rx_frame/rx_clear counters

ath10k fw_stats rx_frame/rx_clear counters

[Sergey Naumov]

Hi all.

I'm using barrier breaker OpenWRT on TP-link Archer C7 v2.0 router and
looking at /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats content.
As far as I understand "RX frame" accounts just rx of our and all the
other APs on the same channel, while "RX clear" also accounts tx of
our AP and non-wifi interference.
At least it is true for ath9k with 2.4GHz chip on the same router,
where "channel busy time" from survey report is always greater than
"channel receive time".

But for ath10k I see that with absense of the traffic to/from our AP,
"RX frame" register value is always increased a little bit more than a
value of "RX clear" register, and it is strange.

Do you know what could be a reason?

P.S. I tried new Chaos Calmer RC1 OpenWRT release with updated ath10k
driver and binary firmware and there these low-level stats are
unavaiable (file /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats
exists but read returns error).

Thanks in advance,
Sergey.

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k fw_stats rx_frame/rx_clear counters

[Michal Kazior]

On 11 June 2015 at 23:49, Sergey Naumov <sknaumov@gmail.com> wrote:
> Hi all.
>
> I'm using barrier breaker OpenWRT on TP-link Archer C7 v2.0 router and
> looking at /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats content.
> As far as I understand "RX frame" accounts just rx of our and all the
> other APs on the same channel, while "RX clear" also accounts tx of
> our AP and non-wifi interference.
> At least it is true for ath9k with 2.4GHz chip on the same router,
> where "channel busy time" from survey report is always greater than
> "channel receive time".
>
> But for ath10k I see that with absense of the traffic to/from our AP,
> "RX frame" register value is always increased a little bit more than a
> value of "RX clear" register, and it is strange.
>
> Do you know what could be a reason?

What is the interval you're polling the values at? There's a buggy 24
second wraparound on these cycle count related stats. Maybe you're
hitting that..

Another idea/guess is that firmware doesn't read these values
atomically (I recall ath9k locks CC values via control register before
reading them) and it ends up with inconsistent results.


> P.S. I tried new Chaos Calmer RC1 OpenWRT release with updated ath10k
> driver and binary firmware and there these low-level stats are
> unavaiable (file /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats
> exists but read returns error).

The firmware stats interface has a very clunky and unstable ABI. It's
broken often by firmware updates and remains so until someone
notices..

Can you provide more details, please:
 - which revision of CC you're using,
 - what ath10k firmware version is used,
 - what compat package version ath10k is from.


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k fw_stats rx_frame/rx_clear counters

[Ben Greear]

On 06/12/2015 12:16 AM, Michal Kazior wrote:
> On 11 June 2015 at 23:49, Sergey Naumov <sknaumov@gmail.com> wrote:
>> Hi all.
>>
>> I'm using barrier breaker OpenWRT on TP-link Archer C7 v2.0 router and
>> looking at /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats content.
>> As far as I understand "RX frame" accounts just rx of our and all the
>> other APs on the same channel, while "RX clear" also accounts tx of
>> our AP and non-wifi interference.
>> At least it is true for ath9k with 2.4GHz chip on the same router,
>> where "channel busy time" from survey report is always greater than
>> "channel receive time".
>>
>> But for ath10k I see that with absense of the traffic to/from our AP,
>> "RX frame" register value is always increased a little bit more than a
>> value of "RX clear" register, and it is strange.
>>
>> Do you know what could be a reason?
>
> What is the interval you're polling the values at? There's a buggy 24
> second wraparound on these cycle count related stats. Maybe you're
> hitting that..

Here is a link to my previous email on the wrapping issue..it is not *just*
a matter of polling more often:

https://www.marc.info/?l=linux-wireless&m=143353920909147&w=2

After dealing with this, I see expected results when using 10.1.467 based
firmware (both CT and stock).

I am using WLE900VX NIC, my 4.0.4+ kernel.

Thanks,
Ben

>
> Another idea/guess is that firmware doesn't read these values
> atomically (I recall ath9k locks CC values via control register before
> reading them) and it ends up with inconsistent results.
>
>
>> P.S. I tried new Chaos Calmer RC1 OpenWRT release with updated ath10k
>> driver and binary firmware and there these low-level stats are
>> unavaiable (file /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats
>> exists but read returns error).
>
> The firmware stats interface has a very clunky and unstable ABI. It's
> broken often by firmware updates and remains so until someone
> notices..
>
> Can you provide more details, please:
>   - which revision of CC you're using,
>   - what ath10k firmware version is used,
>   - what compat package version ath10k is from.
>
>
> Michał
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k fw_stats rx_frame/rx_clear counters

[Sergey Naumov]

TP-link Archer C7 5GHz chip is QCA9880-BR4A.
Barrier Breaker compat-wireless package is 2014-05-22 with ath10k
firmware 38eeda3ae6f90fde5546bdd48ee4ff3090f238c0 (rx clear sometimes
is less than rx frame)
Chaos Calmer compat-wireless package is 2015-03-09 with ath10k
firmware da0f85d924226ee30c46e037120621c9e192b39e (fw_stats aren't
retrievable)

I do not think that the issue I reported is linked to buggy
wraparound, because "RX frame count" from pdev stats is increasing
faster than "RX clear count".
For example here are stats from 2 consecutive calls of "cat
/sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats":

Cycle count diff = 4251412543 - 3864224417 = 387188126
RX clear count diff = 633835870 - 574177256 = 59658614
RX frame count diff = 674834640 - 611992703 = 62841937
TX frame count diff = 14373772 - 12746248 = 1627524

RX frame diff - RX clear diff = 62841937 - 59658614 = 3183323.

I thought that RX clear counter has to always be greater than RX frame
counter, because in theory RX clear (busy) = RX frame + TX frame +
non-wifi interference. And I checked that both TX frame and ACI are
accounted in RX clear and not in RX frame, so I don't understand why
RX frame is greater.

Results presented above are measured with no clients connected to AP.

BTW what I'm trying to do is to make a survey report for ath10k work
in the same way as it works for ath9k, where CCA stats are constantly
updated for the current channel, and I also end up with discarding of
stats if overflow of cycle count occurs. So I just poll for these
stats every 50ms, compute differencies and accumulate them in survey
report if diff is positive for cycle stats.

Thanks,
Sergey.

2015-06-12 6:43 GMT-07:00 Ben Greear <greearb@candelatech.com>:
>
>
> On 06/12/2015 12:16 AM, Michal Kazior wrote:
>>
>> On 11 June 2015 at 23:49, Sergey Naumov <sknaumov@gmail.com> wrote:
>>>
>>> Hi all.
>>>
>>> I'm using barrier breaker OpenWRT on TP-link Archer C7 v2.0 router and
>>> looking at /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats content.
>>> As far as I understand "RX frame" accounts just rx of our and all the
>>> other APs on the same channel, while "RX clear" also accounts tx of
>>> our AP and non-wifi interference.
>>> At least it is true for ath9k with 2.4GHz chip on the same router,
>>> where "channel busy time" from survey report is always greater than
>>> "channel receive time".
>>>
>>> But for ath10k I see that with absense of the traffic to/from our AP,
>>> "RX frame" register value is always increased a little bit more than a
>>> value of "RX clear" register, and it is strange.
>>>
>>> Do you know what could be a reason?
>>
>>
>> What is the interval you're polling the values at? There's a buggy 24
>> second wraparound on these cycle count related stats. Maybe you're
>> hitting that..
>
>
> Here is a link to my previous email on the wrapping issue..it is not *just*
> a matter of polling more often:
>
> https://www.marc.info/?l=linux-wireless&m=143353920909147&w=2
>
> After dealing with this, I see expected results when using 10.1.467 based
> firmware (both CT and stock).
>
> I am using WLE900VX NIC, my 4.0.4+ kernel.
>
> Thanks,
> Ben
>
>>
>> Another idea/guess is that firmware doesn't read these values
>> atomically (I recall ath9k locks CC values via control register before
>> reading them) and it ends up with inconsistent results.
>>
>>
>>> P.S. I tried new Chaos Calmer RC1 OpenWRT release with updated ath10k
>>> driver and binary firmware and there these low-level stats are
>>> unavaiable (file /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats
>>> exists but read returns error).
>>
>>
>> The firmware stats interface has a very clunky and unstable ABI. It's
>> broken often by firmware updates and remains so until someone
>> notices..
>>
>> Can you provide more details, please:
>>   - which revision of CC you're using,
>>   - what ath10k firmware version is used,
>>   - what compat package version ath10k is from.
>>
>>
>> Michał
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k fw_stats rx_frame/rx_clear counters

[Adrian Chadd]

I'll go see if I can dig up how this works on the 11ac NICs. I have a
sneaking suspicion that the ext20, ext40, ext80 channel bits are
making things different.


-a

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k fw_stats rx_frame/rx_clear counters

[Ben Greear]

On 06/12/2015 10:51 AM, Sergey Naumov wrote:
> TP-link Archer C7 5GHz chip is QCA9880-BR4A.
> Barrier Breaker compat-wireless package is 2014-05-22 with ath10k
> firmware 38eeda3ae6f90fde5546bdd48ee4ff3090f238c0 (rx clear sometimes
> is less than rx frame)
> Chaos Calmer compat-wireless package is 2015-03-09 with ath10k
> firmware da0f85d924226ee30c46e037120621c9e192b39e (fw_stats aren't
> retrievable)
> 
> I do not think that the issue I reported is linked to buggy
> wraparound, because "RX frame count" from pdev stats is increasing
> faster than "RX clear count".
> For example here are stats from 2 consecutive calls of "cat
> /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats":
> 
> Cycle count diff = 4251412543 - 3864224417 = 387188126
> RX clear count diff = 633835870 - 574177256 = 59658614
> RX frame count diff = 674834640 - 611992703 = 62841937
> TX frame count diff = 14373772 - 12746248 = 1627524
> 
> RX frame diff - RX clear diff = 62841937 - 59658614 = 3183323.
> 
> I thought that RX clear counter has to always be greater than RX frame
> counter, because in theory RX clear (busy) = RX frame + TX frame +
> non-wifi interference. And I checked that both TX frame and ACI are
> accounted in RX clear and not in RX frame, so I don't understand why
> RX frame is greater.
> 
> Results presented above are measured with no clients connected to AP.
> 
> BTW what I'm trying to do is to make a survey report for ath10k work
> in the same way as it works for ath9k, where CCA stats are constantly
> updated for the current channel, and I also end up with discarding of
> stats if overflow of cycle count occurs. So I just poll for these
> stats every 50ms, compute differencies and accumulate them in survey
> report if diff is positive for cycle stats.

When the cycle count overflows, you also have to take new basline for the other
counters since they will have been shifted right by 1 bit (ie, divided by 2)
whenever the cycle counter overflowed.

I have only been paying attention to the cycle and 'clear' counters,
if there is weirdness in the others I would not have noticed it.

Thanks,
Ben


> 
> Thanks,
> Sergey.
> 
> 2015-06-12 6:43 GMT-07:00 Ben Greear <greearb@candelatech.com>:
>>
>>
>> On 06/12/2015 12:16 AM, Michal Kazior wrote:
>>>
>>> On 11 June 2015 at 23:49, Sergey Naumov <sknaumov@gmail.com> wrote:
>>>>
>>>> Hi all.
>>>>
>>>> I'm using barrier breaker OpenWRT on TP-link Archer C7 v2.0 router and
>>>> looking at /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats content.
>>>> As far as I understand "RX frame" accounts just rx of our and all the
>>>> other APs on the same channel, while "RX clear" also accounts tx of
>>>> our AP and non-wifi interference.
>>>> At least it is true for ath9k with 2.4GHz chip on the same router,
>>>> where "channel busy time" from survey report is always greater than
>>>> "channel receive time".
>>>>
>>>> But for ath10k I see that with absense of the traffic to/from our AP,
>>>> "RX frame" register value is always increased a little bit more than a
>>>> value of "RX clear" register, and it is strange.
>>>>
>>>> Do you know what could be a reason?
>>>
>>>
>>> What is the interval you're polling the values at? There's a buggy 24
>>> second wraparound on these cycle count related stats. Maybe you're
>>> hitting that..
>>
>>
>> Here is a link to my previous email on the wrapping issue..it is not *just*
>> a matter of polling more often:
>>
>> https://www.marc.info/?l=linux-wireless&m=143353920909147&w=2
>>
>> After dealing with this, I see expected results when using 10.1.467 based
>> firmware (both CT and stock).
>>
>> I am using WLE900VX NIC, my 4.0.4+ kernel.
>>
>> Thanks,
>> Ben
>>
>>>
>>> Another idea/guess is that firmware doesn't read these values
>>> atomically (I recall ath9k locks CC values via control register before
>>> reading them) and it ends up with inconsistent results.
>>>
>>>
>>>> P.S. I tried new Chaos Calmer RC1 OpenWRT release with updated ath10k
>>>> driver and binary firmware and there these low-level stats are
>>>> unavaiable (file /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats
>>>> exists but read returns error).
>>>
>>>
>>> The firmware stats interface has a very clunky and unstable ABI. It's
>>> broken often by firmware updates and remains so until someone
>>> notices..
>>>
>>> Can you provide more details, please:
>>>   - which revision of CC you're using,
>>>   - what ath10k firmware version is used,
>>>   - what compat package version ath10k is from.
>>>
>>>
>>> Michał
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>
>>
>> --
>> Ben Greear <greearb@candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
> 
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k fw_stats rx_frame/rx_clear counters

[Sergey Naumov]

Hi All.

I've just tried ath10k from compat-wireless-2016-01-10 (OpenWRT Chaos
Calmer 15.05.1).

For ath10k from older compat-wireless packages I made a patch that
periodically updates survey stats by calling

ath10k_wmi_request_stats(ar, WMI_REQUEST_PEER_STAT)

to get low-level pdev ath10k_target_stats and then convert them to
survey stats in

ath10k_debug_read_target_stats().

This way I had the following output:

root@OpenWrt:/# iw dev wlan0 survey dump
Survey data from wlan0
        frequency:                      5180 MHz [in use]
        noise:                          -103 dBm
        channel active time:            1858553 ms            <- These
stats grow on each call
        channel busy time:              1164399 ms            <-
        channel receive time:           665672 ms             <-
        channel transmit time:          3784 ms                <-
Survey data from wlan0
        frequency:                      5200 MHz
...

Stats I've managed to get this way were quite accurate and correspond
with reality.


In ath10k from compat-wireless-2016-01-10 I see that there was an
attempt to add survey info, but using wmi_chain_info_event stats
instead of pdev.

So the question is:
1. Why it was decided to use wmi_chain_info_event stats? After all,
unlike wmi_pdev_stats_base, they don't have tx_frame_count and
rx_frame_count, so channel receive and transmit time couldn't be
populated.
2. Why it doesn't work? =) In OpenWRT 15.15.1 for QCA9880-BR4A I get:

root@OpenWrt:/# iw dev wlan0 survey dump
Survey data from wlan0
        frequency:                      5180 MHz [in use]
        noise:                          -102 dBm
        channel active time:            146 ms             <- These
stats never get updated
        channel busy time:              60 ms              <-
Survey data from wlan0
        frequency:                      5200 MHz
        noise:                          -102 dBm
        channel active time:            146 ms
        channel busy time:              68 ms
Survey data from wlan0
        frequency:                      5220 MHz
...

Thanks,
Sergey.

2015-06-12 23:34 GMT+03:00 Ben Greear <greearb@candelatech.com>:
> On 06/12/2015 10:51 AM, Sergey Naumov wrote:
>> TP-link Archer C7 5GHz chip is QCA9880-BR4A.
>> Barrier Breaker compat-wireless package is 2014-05-22 with ath10k
>> firmware 38eeda3ae6f90fde5546bdd48ee4ff3090f238c0 (rx clear sometimes
>> is less than rx frame)
>> Chaos Calmer compat-wireless package is 2015-03-09 with ath10k
>> firmware da0f85d924226ee30c46e037120621c9e192b39e (fw_stats aren't
>> retrievable)
>>
>> I do not think that the issue I reported is linked to buggy
>> wraparound, because "RX frame count" from pdev stats is increasing
>> faster than "RX clear count".
>> For example here are stats from 2 consecutive calls of "cat
>> /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats":
>>
>> Cycle count diff = 4251412543 - 3864224417 = 387188126
>> RX clear count diff = 633835870 - 574177256 = 59658614
>> RX frame count diff = 674834640 - 611992703 = 62841937
>> TX frame count diff = 14373772 - 12746248 = 1627524
>>
>> RX frame diff - RX clear diff = 62841937 - 59658614 = 3183323.
>>
>> I thought that RX clear counter has to always be greater than RX frame
>> counter, because in theory RX clear (busy) = RX frame + TX frame +
>> non-wifi interference. And I checked that both TX frame and ACI are
>> accounted in RX clear and not in RX frame, so I don't understand why
>> RX frame is greater.
>>
>> Results presented above are measured with no clients connected to AP.
>>
>> BTW what I'm trying to do is to make a survey report for ath10k work
>> in the same way as it works for ath9k, where CCA stats are constantly
>> updated for the current channel, and I also end up with discarding of
>> stats if overflow of cycle count occurs. So I just poll for these
>> stats every 50ms, compute differencies and accumulate them in survey
>> report if diff is positive for cycle stats.
>
> When the cycle count overflows, you also have to take new basline for the other
> counters since they will have been shifted right by 1 bit (ie, divided by 2)
> whenever the cycle counter overflowed.
>
> I have only been paying attention to the cycle and 'clear' counters,
> if there is weirdness in the others I would not have noticed it.
>
> Thanks,
> Ben
>
>
>>
>> Thanks,
>> Sergey.
>>
>> 2015-06-12 6:43 GMT-07:00 Ben Greear <greearb@candelatech.com>:
>>>
>>>
>>> On 06/12/2015 12:16 AM, Michal Kazior wrote:
>>>>
>>>> On 11 June 2015 at 23:49, Sergey Naumov <sknaumov@gmail.com> wrote:
>>>>>
>>>>> Hi all.
>>>>>
>>>>> I'm using barrier breaker OpenWRT on TP-link Archer C7 v2.0 router and
>>>>> looking at /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats content.
>>>>> As far as I understand "RX frame" accounts just rx of our and all the
>>>>> other APs on the same channel, while "RX clear" also accounts tx of
>>>>> our AP and non-wifi interference.
>>>>> At least it is true for ath9k with 2.4GHz chip on the same router,
>>>>> where "channel busy time" from survey report is always greater than
>>>>> "channel receive time".
>>>>>
>>>>> But for ath10k I see that with absense of the traffic to/from our AP,
>>>>> "RX frame" register value is always increased a little bit more than a
>>>>> value of "RX clear" register, and it is strange.
>>>>>
>>>>> Do you know what could be a reason?
>>>>
>>>>
>>>> What is the interval you're polling the values at? There's a buggy 24
>>>> second wraparound on these cycle count related stats. Maybe you're
>>>> hitting that..
>>>
>>>
>>> Here is a link to my previous email on the wrapping issue..it is not *just*
>>> a matter of polling more often:
>>>
>>> https://www.marc.info/?l=linux-wireless&m=143353920909147&w=2
>>>
>>> After dealing with this, I see expected results when using 10.1.467 based
>>> firmware (both CT and stock).
>>>
>>> I am using WLE900VX NIC, my 4.0.4+ kernel.
>>>
>>> Thanks,
>>> Ben
>>>
>>>>
>>>> Another idea/guess is that firmware doesn't read these values
>>>> atomically (I recall ath9k locks CC values via control register before
>>>> reading them) and it ends up with inconsistent results.
>>>>
>>>>
>>>>> P.S. I tried new Chaos Calmer RC1 OpenWRT release with updated ath10k
>>>>> driver and binary firmware and there these low-level stats are
>>>>> unavaiable (file /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats
>>>>> exists but read returns error).
>>>>
>>>>
>>>> The firmware stats interface has a very clunky and unstable ABI. It's
>>>> broken often by firmware updates and remains so until someone
>>>> notices..
>>>>
>>>> Can you provide more details, please:
>>>>   - which revision of CC you're using,
>>>>   - what ath10k firmware version is used,
>>>>   - what compat package version ath10k is from.
>>>>
>>>>
>>>> Michał
>>>>
>>>> _______________________________________________
>>>> ath10k mailing list
>>>> ath10k@lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>
>>>
>>> --
>>> Ben Greear <greearb@candelatech.com>
>>> Candela Technologies Inc  http://www.candelatech.com
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k fw_stats rx_frame/rx_clear counters

[Ben Greear]

At most, I might can help with issues you see with CT 10.1 firmware
and CT ath10k driver.

In case it helps, we get these counters via ethtool and it appears
to be mostly accurate last time we did detailed testing.

Thanks,
Ben

On 09/08/2016 05:00 AM, Sergey Naumov wrote:
> Hi All.
>
> I've just tried ath10k from compat-wireless-2016-01-10 (OpenWRT Chaos
> Calmer 15.05.1).
>
> For ath10k from older compat-wireless packages I made a patch that
> periodically updates survey stats by calling
>
> ath10k_wmi_request_stats(ar, WMI_REQUEST_PEER_STAT)
>
> to get low-level pdev ath10k_target_stats and then convert them to
> survey stats in
>
> ath10k_debug_read_target_stats().
>
> This way I had the following output:
>
> root@OpenWrt:/# iw dev wlan0 survey dump
> Survey data from wlan0
>         frequency:                      5180 MHz [in use]
>         noise:                          -103 dBm
>         channel active time:            1858553 ms            <- These
> stats grow on each call
>         channel busy time:              1164399 ms            <-
>         channel receive time:           665672 ms             <-
>         channel transmit time:          3784 ms                <-
> Survey data from wlan0
>         frequency:                      5200 MHz
> ...
>
> Stats I've managed to get this way were quite accurate and correspond
> with reality.
>
>
> In ath10k from compat-wireless-2016-01-10 I see that there was an
> attempt to add survey info, but using wmi_chain_info_event stats
> instead of pdev.
>
> So the question is:
> 1. Why it was decided to use wmi_chain_info_event stats? After all,
> unlike wmi_pdev_stats_base, they don't have tx_frame_count and
> rx_frame_count, so channel receive and transmit time couldn't be
> populated.
> 2. Why it doesn't work? =) In OpenWRT 15.15.1 for QCA9880-BR4A I get:
>
> root@OpenWrt:/# iw dev wlan0 survey dump
> Survey data from wlan0
>         frequency:                      5180 MHz [in use]
>         noise:                          -102 dBm
>         channel active time:            146 ms             <- These
> stats never get updated
>         channel busy time:              60 ms              <-
> Survey data from wlan0
>         frequency:                      5200 MHz
>         noise:                          -102 dBm
>         channel active time:            146 ms
>         channel busy time:              68 ms
> Survey data from wlan0
>         frequency:                      5220 MHz
> ...
>
> Thanks,
> Sergey.
>
> 2015-06-12 23:34 GMT+03:00 Ben Greear <greearb@candelatech.com>:
>> On 06/12/2015 10:51 AM, Sergey Naumov wrote:
>>> TP-link Archer C7 5GHz chip is QCA9880-BR4A.
>>> Barrier Breaker compat-wireless package is 2014-05-22 with ath10k
>>> firmware 38eeda3ae6f90fde5546bdd48ee4ff3090f238c0 (rx clear sometimes
>>> is less than rx frame)
>>> Chaos Calmer compat-wireless package is 2015-03-09 with ath10k
>>> firmware da0f85d924226ee30c46e037120621c9e192b39e (fw_stats aren't
>>> retrievable)
>>>
>>> I do not think that the issue I reported is linked to buggy
>>> wraparound, because "RX frame count" from pdev stats is increasing
>>> faster than "RX clear count".
>>> For example here are stats from 2 consecutive calls of "cat
>>> /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats":
>>>
>>> Cycle count diff = 4251412543 - 3864224417 = 387188126
>>> RX clear count diff = 633835870 - 574177256 = 59658614
>>> RX frame count diff = 674834640 - 611992703 = 62841937
>>> TX frame count diff = 14373772 - 12746248 = 1627524
>>>
>>> RX frame diff - RX clear diff = 62841937 - 59658614 = 3183323.
>>>
>>> I thought that RX clear counter has to always be greater than RX frame
>>> counter, because in theory RX clear (busy) = RX frame + TX frame +
>>> non-wifi interference. And I checked that both TX frame and ACI are
>>> accounted in RX clear and not in RX frame, so I don't understand why
>>> RX frame is greater.
>>>
>>> Results presented above are measured with no clients connected to AP.
>>>
>>> BTW what I'm trying to do is to make a survey report for ath10k work
>>> in the same way as it works for ath9k, where CCA stats are constantly
>>> updated for the current channel, and I also end up with discarding of
>>> stats if overflow of cycle count occurs. So I just poll for these
>>> stats every 50ms, compute differencies and accumulate them in survey
>>> report if diff is positive for cycle stats.
>>
>> When the cycle count overflows, you also have to take new basline for the other
>> counters since they will have been shifted right by 1 bit (ie, divided by 2)
>> whenever the cycle counter overflowed.
>>
>> I have only been paying attention to the cycle and 'clear' counters,
>> if there is weirdness in the others I would not have noticed it.
>>
>> Thanks,
>> Ben
>>
>>
>>>
>>> Thanks,
>>> Sergey.
>>>
>>> 2015-06-12 6:43 GMT-07:00 Ben Greear <greearb@candelatech.com>:
>>>>
>>>>
>>>> On 06/12/2015 12:16 AM, Michal Kazior wrote:
>>>>>
>>>>> On 11 June 2015 at 23:49, Sergey Naumov <sknaumov@gmail.com> wrote:
>>>>>>
>>>>>> Hi all.
>>>>>>
>>>>>> I'm using barrier breaker OpenWRT on TP-link Archer C7 v2.0 router and
>>>>>> looking at /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats content.
>>>>>> As far as I understand "RX frame" accounts just rx of our and all the
>>>>>> other APs on the same channel, while "RX clear" also accounts tx of
>>>>>> our AP and non-wifi interference.
>>>>>> At least it is true for ath9k with 2.4GHz chip on the same router,
>>>>>> where "channel busy time" from survey report is always greater than
>>>>>> "channel receive time".
>>>>>>
>>>>>> But for ath10k I see that with absense of the traffic to/from our AP,
>>>>>> "RX frame" register value is always increased a little bit more than a
>>>>>> value of "RX clear" register, and it is strange.
>>>>>>
>>>>>> Do you know what could be a reason?
>>>>>
>>>>>
>>>>> What is the interval you're polling the values at? There's a buggy 24
>>>>> second wraparound on these cycle count related stats. Maybe you're
>>>>> hitting that..
>>>>
>>>>
>>>> Here is a link to my previous email on the wrapping issue..it is not *just*
>>>> a matter of polling more often:
>>>>
>>>> https://www.marc.info/?l=linux-wireless&m=143353920909147&w=2
>>>>
>>>> After dealing with this, I see expected results when using 10.1.467 based
>>>> firmware (both CT and stock).
>>>>
>>>> I am using WLE900VX NIC, my 4.0.4+ kernel.
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>>>
>>>>> Another idea/guess is that firmware doesn't read these values
>>>>> atomically (I recall ath9k locks CC values via control register before
>>>>> reading them) and it ends up with inconsistent results.
>>>>>
>>>>>
>>>>>> P.S. I tried new Chaos Calmer RC1 OpenWRT release with updated ath10k
>>>>>> driver and binary firmware and there these low-level stats are
>>>>>> unavaiable (file /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats
>>>>>> exists but read returns error).
>>>>>
>>>>>
>>>>> The firmware stats interface has a very clunky and unstable ABI. It's
>>>>> broken often by firmware updates and remains so until someone
>>>>> notices..
>>>>>
>>>>> Can you provide more details, please:
>>>>>   - which revision of CC you're using,
>>>>>   - what ath10k firmware version is used,
>>>>>   - what compat package version ath10k is from.
>>>>>
>>>>>
>>>>> Michał
>>>>>
>>>>> _______________________________________________
>>>>> ath10k mailing list
>>>>> ath10k@lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>>
>>>>
>>>> --
>>>> Ben Greear <greearb@candelatech.com>
>>>> Candela Technologies Inc  http://www.candelatech.com
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>
>>
>>
>> --
>> Ben Greear <greearb@candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k