[PATCH] ath10k: Fix survey information reporting
dreamfly281 at gmail.com
Fri Jun 5 14:39:45 PDT 2015
On Fri, Jun 5, 2015 at 2:20 PM, Ben Greear <greearb at candelatech.com> wrote:
> On 06/05/2015 02:00 PM, YanBo wrote:
>> On Fri, Jun 5, 2015 at 1:18 PM, Ben Greear <greearb at candelatech.com> wrote:
>>> I think the wrapping might be even more weird that previously suspected. Here is output from my
>>> 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.
Exactly that the FW used to fixed this issue, as it is a HW
limitation, they is no
better way to correct it without faster polling
More information about the ath10k