Re: ath10k fw_stats rx_frame/rx_clear counters

[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