ath10k fw_stats rx_frame/rx_clear counters
Ben Greear
greearb at candelatech.com
Thu Sep 8 11:15:32 PDT 2016
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 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
>>
>
--
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc http://www.candelatech.com
More information about the ath10k
mailing list