[PATCH] ath10k: Fix survey information reporting

[PATCH] ath10k: Fix survey information reporting

[Vasanthakumar Thiagarajan]

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;
 	}
 
-- 
1.9.1


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH] ath10k: Fix survey information reporting

[Vasanthakumar Thiagarajan]

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;
 	}
 
-- 
1.9.1

Re: [PATCH] ath10k: Fix survey information reporting

[Kalle Valo]

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.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] ath10k: Fix survey information reporting

[Kalle Valo]

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.

-- 
Kalle Valo

Re: [PATCH] ath10k: Fix survey information reporting

[Ben Greear]

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;
>  	}
>  
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] ath10k: Fix survey information reporting

[Ben Greear]

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;
>  	}
>  
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH] ath10k: Fix survey information reporting

[YanBo]

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

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] ath10k: Fix survey information reporting

[YanBo]

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

Re: [PATCH] ath10k: Fix survey information reporting

[Ben Greear]

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

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] ath10k: Fix survey information reporting

[Ben Greear]

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

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH] ath10k: Fix survey information reporting

[Ben Greear]

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
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] ath10k: Fix survey information reporting

[Ben Greear]

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
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH] ath10k: Fix survey information reporting

[YanBo]

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

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] ath10k: Fix survey information reporting

[YanBo]

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

Re: [PATCH] ath10k: Fix survey information reporting

[Ben Greear]

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
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] ath10k: Fix survey information reporting

[Ben Greear]

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
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH] ath10k: Fix survey information reporting

[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

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] ath10k: Fix survey information reporting

[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

Re: [PATCH] ath10k: Fix survey information reporting

[YanBo]

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

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] ath10k: Fix survey information reporting

[YanBo]

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