| Message ID | 1430829048-22549-1-git-send-email-vthiagar@qti.qualcomm.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Kalle Valo |
| Headers | show |
Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> writes: > Rx clear count reported in wmi_chan_info_event is actually channel_busy_count > not rx_frame_count. Send rx_clear_count through time_busy of survey_info > and set SURVEY_INFO_TIME_BUSY in filled. > > iw wlan0 survey dump > > urvey data from wlan0 > frequency: 5180 MHz [in use] > noise: -103 dBm > channel active time: 150 ms > channel busy time: 22 ms > Survey data from wlan0 > frequency: 5200 MHz > noise: -102 dBm > channel active time: 146 ms > channel busy time: 0 ms > > Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Thanks, applied. I actually applied this already on the 11th but apparently forgot to send an email.
I applied these and some other related patches to my hacked-upon 4.0.4, but I am seeing some inconsistencies between how ath10k and ath9k reports survey info. I am using my CT firmware based on 10.1. ath9k reports ever-increasing counters for the channel time and busy time. With ath10k, it reports the same values until I do a scan again, and even then, it is not additive. First, should the value only update when we do a scan? And second, should ath10k report ever increasing totals to match ath9k behaviour? Thanks, Ben On 05/05/2015 05:30 AM, Vasanthakumar Thiagarajan wrote: > Rx clear count reported in wmi_chan_info_event is actually channel_busy_count > not rx_frame_count. Send rx_clear_count through time_busy of survey_info > and set SURVEY_INFO_TIME_BUSY in filled. > > iw wlan0 survey dump > > urvey data from wlan0 > frequency: 5180 MHz [in use] > noise: -103 dBm > channel active time: 150 ms > channel busy time: 22 ms > Survey data from wlan0 > frequency: 5200 MHz > noise: -102 dBm > channel active time: 146 ms > channel busy time: 0 ms > > Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> > --- > drivers/net/wireless/ath/ath10k/wmi.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c > index ebaa096..0fabe68 100644 > --- a/drivers/net/wireless/ath/ath10k/wmi.c > +++ b/drivers/net/wireless/ath/ath10k/wmi.c > @@ -1645,10 +1645,10 @@ void ath10k_wmi_event_chan_info(struct ath10k *ar, struct sk_buff *skb) > > survey = &ar->survey[idx]; > survey->time = WMI_CHAN_INFO_MSEC(cycle_count); > - survey->time_rx = WMI_CHAN_INFO_MSEC(rx_clear_count); > + survey->time_busy = WMI_CHAN_INFO_MSEC(rx_clear_count); > survey->noise = noise_floor; > survey->filled = SURVEY_INFO_TIME | > - SURVEY_INFO_TIME_RX | > + SURVEY_INFO_TIME_BUSY | > SURVEY_INFO_NOISE_DBM; > } > >
On Fri, Jun 5, 2015 at 10:14 AM, Ben Greear <greearb@candelatech.com> wrote: > I applied these and some other related patches to my hacked-upon 4.0.4, but > I am seeing some inconsistencies between how ath10k and ath9k > reports survey info. I am using my CT firmware based on 10.1. > > ath9k reports ever-increasing counters for the channel time > and busy time. > > With ath10k, it reports the same values until I do a scan > again, and even then, it is not additive. > > First, should the value only update when we do a scan? > > And second, should ath10k report ever increasing totals > to match ath9k behaviour? > It should be match with ath9k, but the ath10k doesn't accumulate the survey count at currently code, I drafted a patch to fix this issue, will send to public mailist soon. BR /Yanbo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/05/2015 12:10 PM, YanBo wrote: > On Fri, Jun 5, 2015 at 10:14 AM, Ben Greear <greearb@candelatech.com> wrote: >> I applied these and some other related patches to my hacked-upon 4.0.4, but >> I am seeing some inconsistencies between how ath10k and ath9k >> reports survey info. I am using my CT firmware based on 10.1. >> >> ath9k reports ever-increasing counters for the channel time >> and busy time. >> >> With ath10k, it reports the same values until I do a scan >> again, and even then, it is not additive. >> >> First, should the value only update when we do a scan? >> >> And second, should ath10k report ever increasing totals >> to match ath9k behaviour? >> > > It should be match with ath9k, but the ath10k doesn't accumulate the > survey count at currently code, > I drafted a patch to fix this issue, will send to public mailist soon. I notice you can get current cycle stats out of the pdev stats as well, and those update every time you ask firmware for stats. It won't be 100% accurate because you don't know when firmware was off-channel or not, but I guess it will be better for me than nothing. I certainly don't want to be scanning all the time, but grabbing firmware stats already happens when you get ethtool stats, so as long as I poll often enough to catch wraps, I think it will be good enough. I guess to get really accurate values, one would have to hack the firmware to keep its own accumulated stats and properly deal with channel changes. Thanks, Ben
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
Thanks,
Ben
On 06/05/2015 12:22 PM, Ben Greear wrote:
> On 06/05/2015 12:10 PM, YanBo wrote:
>> On Fri, Jun 5, 2015 at 10:14 AM, Ben Greear <greearb@candelatech.com> wrote:
>>> I applied these and some other related patches to my hacked-upon 4.0.4, but
>>> I am seeing some inconsistencies between how ath10k and ath9k
>>> reports survey info. I am using my CT firmware based on 10.1.
>>>
>>> ath9k reports ever-increasing counters for the channel time
>>> and busy time.
>>>
>>> With ath10k, it reports the same values until I do a scan
>>> again, and even then, it is not additive.
>>>
>>> First, should the value only update when we do a scan?
>>>
>>> And second, should ath10k report ever increasing totals
>>> to match ath9k behaviour?
>>>
>>
>> It should be match with ath9k, but the ath10k doesn't accumulate the
>> survey count at currently code,
>> I drafted a patch to fix this issue, will send to public mailist soon.
>
> I notice you can get current cycle stats out of the pdev stats as well,
> and those update every time you ask firmware for stats.
>
> It won't be 100% accurate because you don't know when firmware
> was off-channel or not, but I guess it will be better for me than
> nothing. I certainly don't want to be scanning all the time,
> but grabbing firmware stats already happens when you get ethtool
> stats, so as long as I poll often enough to catch wraps, I think it
> will be good enough.
>
> I guess to get really accurate values, one would have to hack the
> firmware to keep its own accumulated stats and properly deal with
> channel changes.
>
> Thanks,
> Ben
>
On Fri, Jun 5, 2015 at 12:22 PM, Ben Greear <greearb@candelatech.com> wrote: > On 06/05/2015 12:10 PM, YanBo wrote: >> On Fri, Jun 5, 2015 at 10:14 AM, Ben Greear <greearb@candelatech.com> wrote: >>> I applied these and some other related patches to my hacked-upon 4.0.4, but >>> I am seeing some inconsistencies between how ath10k and ath9k >>> reports survey info. I am using my CT firmware based on 10.1. >>> >>> ath9k reports ever-increasing counters for the channel time >>> and busy time. >>> >>> With ath10k, it reports the same values until I do a scan >>> again, and even then, it is not additive. >>> >>> First, should the value only update when we do a scan? >>> >>> And second, should ath10k report ever increasing totals >>> to match ath9k behaviour? >>> >> >> It should be match with ath9k, but the ath10k doesn't accumulate the >> survey count at currently code, >> I drafted a patch to fix this issue, will send to public mailist soon. > > I notice you can get current cycle stats out of the pdev stats as well, > and those update every time you ask firmware for stats. > > It won't be 100% accurate because you don't know when firmware > was off-channel or not, but I guess it will be better for me than > nothing. I certainly don't want to be scanning all the time, > but grabbing firmware stats already happens when you get ethtool > stats, so as long as I poll often enough to catch wraps, I think it > will be good enough. > > I guess to get really accurate values, one would have to hack the > firmware to keep its own accumulated stats and properly deal with > channel changes. > The new FW (from 10.2.4.70 IIRC) add an new WMI interface to supply such kinds of count. BR /Yanbo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. BR /Yanbo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 >
On Fri, Jun 5, 2015 at 2:20 PM, Ben Greear <greearb@candelatech.com> wrote: > 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. > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c index ebaa096..0fabe68 100644 --- a/drivers/net/wireless/ath/ath10k/wmi.c +++ b/drivers/net/wireless/ath/ath10k/wmi.c @@ -1645,10 +1645,10 @@ void ath10k_wmi_event_chan_info(struct ath10k *ar, struct sk_buff *skb) survey = &ar->survey[idx]; survey->time = WMI_CHAN_INFO_MSEC(cycle_count); - survey->time_rx = WMI_CHAN_INFO_MSEC(rx_clear_count); + survey->time_busy = WMI_CHAN_INFO_MSEC(rx_clear_count); survey->noise = noise_floor; survey->filled = SURVEY_INFO_TIME | - SURVEY_INFO_TIME_RX | + SURVEY_INFO_TIME_BUSY | SURVEY_INFO_NOISE_DBM; }
Rx clear count reported in wmi_chan_info_event is actually channel_busy_count not rx_frame_count. Send rx_clear_count through time_busy of survey_info and set SURVEY_INFO_TIME_BUSY in filled. iw wlan0 survey dump urvey data from wlan0 frequency: 5180 MHz [in use] noise: -103 dBm channel active time: 150 ms channel busy time: 22 ms Survey data from wlan0 frequency: 5200 MHz noise: -102 dBm channel active time: 146 ms channel busy time: 0 ms Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> --- drivers/net/wireless/ath/ath10k/wmi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)