On 06/05/2015 02:00 PM, YanBo wrote: > On Fri, Jun 5, 2015 at 1:18 PM, Ben Greear <greearb@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
