Re: [PATCH] ath10k: Fix survey information reporting

[Ben Greear <greearb@candelatech.com>]

On 06/05/2015 02:00 PM, YanBo wrote:
> On Fri, Jun 5, 2015 at 1:18 PM, Ben Greear <greearb@candelatech.com> wrote:
>> I think the wrapping might be even more weird that previously suspected.  Here is output from my
>> system.
>>
>> It looks to me that when cycle count overflows, it right-shifts all of these
>> counters one bit.  Clever, I guess, but surely a pain in the ass to deal with!
>>
>>
>> while true; do cat /debug/ieee80211/wiphy0/ath10k/fw_stats|head -10|tail -4; date; echo;sleep 1; done
>> ....
>>                 TX frame count  131810463
>>                 RX frame count 2326362883
>>                 RX clear count 2542947851
>>                    Cycle count 4180338939
>> Fri Jun  5 13:13:48 PDT 2015
>>
>>                 TX frame count  134407497
>>                 RX frame count 2374518035
>>                 RX clear count 2595337341
>>                    Cycle count 4269010333
>> Fri Jun  5 13:13:49 PDT 2015
>>
>>                 TX frame count   69523007
>>                 RX frame count 1229973316
>>                 RX clear count 1344131636
>>                    Cycle count 2210412416
>> Fri Jun  5 13:13:50 PDT 2015
>>
>>                 TX frame count   72305753
>>                 RX frame count 1280184579
>>                 RX clear count 1398937635
>>                    Cycle count 2299234941
>> Fri Jun  5 13:13:51 PDT 2015
>>
>>                 TX frame count   75050021
>>                 RX frame count 1330205664
>>                 RX clear count 1453548082
>>                    Cycle count 2387901854
>> Fri Jun  5 13:13:52 PDT 2015
>>
>>
> The scan count is 32 bits hence, it will wrap rapidly with 24 seconds
> cycle, the new WMI interface will
> supply these count in 64 bits to avoid such issue.

That is not the problem... you can just sample often to resolve that.

The problem is that the other 3 are divided by 2 at time when the main
cycle-counter counter wraps.  So as far as I can tell, you cannot
actually calculate precise totals from old and new values for the tx/rx/rx-clear
counters if cycle-counter has wrapped since you last read stats.

Only way I can see to deal with it is to sample often enough that I can
afford to throw away samples where cycle-count wraps.  With this implemented,
I see ath10k 'activity' calculation the same as ath9k.

This wrap logic is coming out of the hardware registers as far as I
can tell, so I'm not sure that just firmware changes can really resolve
this fully.

If all they are doing is implementing faster polling in the firmware
itself, that seems like a waste of effort and precious instruction RAM.

Maybe newer hardware will act in a more sane manner so we can deal with
normal 32-bit wraps.

Thanks,
Ben

> 
> BR /Yanbo
> 


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