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 <[email protected]>
---
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;
}
--
1.9.1
Vasanthakumar Thiagarajan <[email protected]> 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 <[email protected]>
Thanks, applied.
I actually applied this already on the 11th but apparently forgot to
send an email.
--
Kalle Valo
On 06/05/2015 12:10 PM, YanBo wrote:
> On Fri, Jun 5, 2015 at 10:14 AM, Ben Greear <[email protected]> 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
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Fri, Jun 5, 2015 at 10:14 AM, Ben Greear <[email protected]> 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
On Fri, Jun 5, 2015 at 1:18 PM, Ben Greear <[email protected]> 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
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 <[email protected]> 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
>
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Fri, Jun 5, 2015 at 2:20 PM, Ben Greear <[email protected]> wrote:
> On 06/05/2015 02:00 PM, YanBo wrote:
>> On Fri, Jun 5, 2015 at 1:18 PM, Ben Greear <[email protected]> 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
On Fri, Jun 5, 2015 at 12:22 PM, Ben Greear <[email protected]> wrote:
> On 06/05/2015 12:10 PM, YanBo wrote:
>> On Fri, Jun 5, 2015 at 10:14 AM, Ben Greear <[email protected]> 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
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 <[email protected]>
> ---
> 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;
> }
>
>
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 06/05/2015 02:00 PM, YanBo wrote:
> On Fri, Jun 5, 2015 at 1:18 PM, Ben Greear <[email protected]> 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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com