Re: ath10k fw_stats rx_frame/rx_clear counters

[Sergey Naumov <sknaumov@gmail.com>]

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