ath10k fw_stats rx_frame/rx_clear counters
Sergey Naumov
sknaumov at gmail.com
Thu Sep 8 05:00:11 PDT 2016
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 at 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 at 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 at 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 at candelatech.com>:
>>>
>>>
>>> On 06/12/2015 12:16 AM, Michal Kazior wrote:
>>>>
>>>> On 11 June 2015 at 23:49, Sergey Naumov <sknaumov at 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 at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>
>>>
>>> --
>>> Ben Greear <greearb at candelatech.com>
>>> Candela Technologies Inc http://www.candelatech.com
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
More information about the ath10k
mailing list