On Fri, Jun 5, 2015 at 2:20 PM, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: > 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. > 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 Thanks BR /Yanbo -- 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
