* Re: problem on ACS
[not found] ` <COL114-W59BDCD7915EEDAF4BEE71A8A4E0@phx.gbl>
@ 2011-07-25 20:32 ` Luis R. Rodriguez
2011-07-25 23:35 ` Luis R. Rodriguez
0 siblings, 1 reply; 17+ messages in thread
From: Luis R. Rodriguez @ 2011-07-25 20:32 UTC (permalink / raw)
To: MingAnn Ng; +Cc: linux-wireless
On Thu, Jul 21, 2011 at 8:13 PM, MingAnn Ng <devil_eddie01@hotmail.com> wrote:
> Hi Luis,
>
> I am thinking of using the ACS application for channel selection on IBSS
> network. I had run a test with the current git. But the result is not so
> convincing.
>
> 10 surveys for 2412 MHz: 11.382248 12.847997 13.223471 13.403065
> 13.454694 13.529891 12.556324 13.573309 13.616969 13.645601
> 10 surveys for 2417 MHz: 12.678072 10.299560 -inf -inf 9.678072 -inf -inf
> -inf -inf -inf
> 10 surveys for 2422 MHz: -inf -inf -inf -inf -inf -inf -inf -inf -inf
> -inf
> 10 surveys for 2427 MHz: -inf -inf 12.192645 -inf -inf -inf -inf -inf
> -inf -inf
> 10 surveys for 2432 MHz: -inf 9.192645 12.777608 12.192645 12.192645 -inf
> 12.192645 -inf 10.093109 12.192645
> 10 surveys for 2437 MHz: 11.192645 -inf 11.000000 10.093109 10.093109
> 11.192645 -inf 11.192645 -inf -inf
> 10 surveys for 2442 MHz: 10.192645 10.093109 -inf 10.061401 11.192645
> -inf -inf -inf 11.192645 10.093109
> 10 surveys for 2447 MHz: -inf -inf -inf 11.777608 -inf 10.192645 -inf
> -inf -inf -inf
> 10 surveys for 2452 MHz: 11.192645 -inf -inf 11.192645 -inf -inf -inf
> 13.777608 11.337035 10.830075
> 10 surveys for 2457 MHz: 10.192645 -inf -inf -inf -inf -inf -inf -inf
> -inf -inf
> 10 surveys for 2462 MHz: 9.540568 9.192645 10.283793 8.476438 -inf -inf
> -inf -inf 10.192645 -inf
> 10 surveys for 2467 MHz: -inf -inf -inf -inf -inf -inf 9.752072 -inf -inf
> -inf
> 10 surveys for 2472 MHz: -inf -inf 10.192645 -inf -inf -inf -inf -inf
> 7.714598 -inf
> 10 surveys for 5180 MHz: 2.000000 1.830075 1.000000 0.678072 2.000000
> 2.000000 2.000000 0.678072 2.000000 2.000000
> 10 surveys for 5200 MHz: 2.000000 1.678072 2.000000 2.000000 2.000000
> 2.000000 1.678072 2.000000 0.678072 0.678072
> 10 surveys for 5220 MHz: 2.000000 1.415037 2.000000 0.000000 2.000000
> 2.000000 1.678072 2.000000 2.000000 2.000000
> 10 surveys for 5240 MHz: 3.000000 3.000000 3.000000 1.245112 3.000000
> 3.000000 3.000000 2.678072 2.000000 3.000000
> 10 surveys for 5260 MHz: 3.000000 2.000000 3.000000 3.000000 3.000000
> 3.000000 2.000000 2.678072 2.000000 2.678072
> 10 surveys for 5280 MHz: 3.000000 1.415037 3.000000 1.415037 1.678072
> 2.000000 1.245112 3.000000 3.000000 2.678072
> 10 surveys for 5300 MHz: 3.000000 3.000000 3.000000 1.415037 3.000000
> 3.000000 3.000000 2.000000 3.000000 3.000000
> 10 surveys for 5320 MHz: 3.000000 3.000000 3.000000 3.000000 3.000000
> 2.678072 3.000000 1.415037 3.000000 2.000000
> 10 surveys for 5500 MHz: -1.000000 -2.000000 -1.000000 -2.321928
> -1.321928 -1.321928 -1.000000 -2.321928 -1.000000 -2.459432
> 10 surveys for 5520 MHz: -2.392317 -1.169925 -1.169925 -0.807355
> -1.906891 -1.169925 -1.169925 -1.169925 -1.700440 -0.807355
> 10 surveys for 5540 MHz: -1.169925 -2.643856 -1.169925 -2.087463
> -1.169925 -1.169925 -2.523562 -1.169925 -1.169925 -1.169925
> 10 surveys for 5560 MHz: -1.169925 -1.169925 -2.643856 -1.169925
> -1.321928 -1.169925 -1.459432 -1.700440 -2.087463 -1.169925
> 10 surveys for 5580 MHz: -1.169925 -1.700440 -1.169925 -1.906891
> -1.321928 -1.169925 -1.169925 -1.169925 -1.169925 -1.169925
> 10 surveys for 5600 MHz: -1.169925 -1.169925 -1.169925 -2.643856
> -0.807355 -2.459432 -1.459432 -1.169925 -1.169925 -1.169925
> 10 surveys for 5620 MHz: -1.169925 -1.321928 -2.087463 -1.169925
> -1.169925 -1.321928 -0.807355 -2.392317 -1.169925 -1.169925
> 10 surveys for 5640 MHz: -2.643856 -1.321928 -1.169925 -2.857981
> -1.169925 -0.584963 -1.169925 -1.169925 -1.169925 -3.643856
> 10 surveys for 5660 MHz: -2.169925 -1.584963 -2.169925 -2.857981
> -1.169925 -1.169925 -1.169925 -1.169925 -1.459432 -1.169925
> 10 surveys for 5680 MHz: -1.169925 -1.169925 -2.643856 -2.700440
> -1.169925 -1.169925 -1.169925 -1.169925 -0.807355 -1.700440
> 10 surveys for 5700 MHz: -2.087463 -1.169925 -1.169925 -1.000000
> -2.459432 -1.169925 -1.169925 -1.169925 -1.169925 -1.169925
> 2412 MHz: 13.123357
> 2417 MHz: -inf
> 2422 MHz: -inf
> 2427 MHz: -inf
> 2432 MHz: -inf
> 2437 MHz: -inf
> 2442 MHz: -inf
> 2447 MHz: -inf
> 2452 MHz: -inf
> 2457 MHz: -inf
> 2462 MHz: -inf
> 2467 MHz: -inf
> 2472 MHz: -inf
> 5180 MHz: 1.618622
> 5200 MHz: 1.671229
> 5220 MHz: 1.709311
> 5240 MHz: 2.692318
> 5260 MHz: 2.635614
> 5280 MHz: 2.243133
> 5300 MHz: 2.741504
> 5320 MHz: 2.709311
> 5500 MHz: -1.574714
> 5520 MHz: -1.346398
> 5540 MHz: -1.544436
> 5560 MHz: -1.506274
> 5580 MHz: -1.311873
> 5600 MHz: -1.438962
> 5620 MHz: -1.378062
> 5640 MHz: -1.690221
> 5660 MHz: -1.609185
> 5680 MHz: -1.487164
> 5700 MHz: -1.373637
> Ideal freq: 2417 MHz
>
>
> The ideal channel is 2417MHz. But there are many interference in 2.4G at my
> testing place. the result for that channel is -inf.
Right..
> I did not understand the
> outcome, maybe you can describe about -infinity and why that this result
> occurs.
Sure, so -inf means the calculation resulted in a value out of bounds
by the used data type. The issue lies in the wide range of values that
we run into for analysis in very noisy environments. One alternative I
considered was to use __float128 instead of long double for the
interference_factor but I was unable to figure out how to print these
correctly.
> will it be causing by scanning time for particular channel is too
> short?
Can you test with the latest ACS patches I posted for hostapd with
debugging and see the values you get there?
Luis
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: problem on ACS
2011-07-25 20:32 ` problem on ACS Luis R. Rodriguez
@ 2011-07-25 23:35 ` Luis R. Rodriguez
2011-07-26 0:13 ` Christian Lamparter
0 siblings, 1 reply; 17+ messages in thread
From: Luis R. Rodriguez @ 2011-07-25 23:35 UTC (permalink / raw)
To: MingAnn Ng; +Cc: linux-wireless
On Mon, Jul 25, 2011 at 1:32 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Thu, Jul 21, 2011 at 8:13 PM, MingAnn Ng <devil_eddie01@hotmail.com> wrote:
>> Hi Luis,
>>
>> I am thinking of using the ACS application for channel selection on IBSS
>> network. I had run a test with the current git. But the result is not so
>> convincing.
>>
>> 10 surveys for 2412 MHz: 11.382248 12.847997 13.223471 13.403065
>> 13.454694 13.529891 12.556324 13.573309 13.616969 13.645601
>> 10 surveys for 2417 MHz: 12.678072 10.299560 -inf -inf 9.678072 -inf -inf
>> -inf -inf -inf
>> 10 surveys for 2422 MHz: -inf -inf -inf -inf -inf -inf -inf -inf -inf
>> -inf
>> 10 surveys for 2427 MHz: -inf -inf 12.192645 -inf -inf -inf -inf -inf
>> -inf -inf
>> 10 surveys for 2432 MHz: -inf 9.192645 12.777608 12.192645 12.192645 -inf
>> 12.192645 -inf 10.093109 12.192645
>> 10 surveys for 2437 MHz: 11.192645 -inf 11.000000 10.093109 10.093109
>> 11.192645 -inf 11.192645 -inf -inf
>> 10 surveys for 2442 MHz: 10.192645 10.093109 -inf 10.061401 11.192645
>> -inf -inf -inf 11.192645 10.093109
>> 10 surveys for 2447 MHz: -inf -inf -inf 11.777608 -inf 10.192645 -inf
>> -inf -inf -inf
>> 10 surveys for 2452 MHz: 11.192645 -inf -inf 11.192645 -inf -inf -inf
>> 13.777608 11.337035 10.830075
>> 10 surveys for 2457 MHz: 10.192645 -inf -inf -inf -inf -inf -inf -inf
>> -inf -inf
>> 10 surveys for 2462 MHz: 9.540568 9.192645 10.283793 8.476438 -inf -inf
>> -inf -inf 10.192645 -inf
>> 10 surveys for 2467 MHz: -inf -inf -inf -inf -inf -inf 9.752072 -inf -inf
>> -inf
>> 10 surveys for 2472 MHz: -inf -inf 10.192645 -inf -inf -inf -inf -inf
>> 7.714598 -inf
>> 10 surveys for 5180 MHz: 2.000000 1.830075 1.000000 0.678072 2.000000
>> 2.000000 2.000000 0.678072 2.000000 2.000000
>> 10 surveys for 5200 MHz: 2.000000 1.678072 2.000000 2.000000 2.000000
>> 2.000000 1.678072 2.000000 0.678072 0.678072
>> 10 surveys for 5220 MHz: 2.000000 1.415037 2.000000 0.000000 2.000000
>> 2.000000 1.678072 2.000000 2.000000 2.000000
>> 10 surveys for 5240 MHz: 3.000000 3.000000 3.000000 1.245112 3.000000
>> 3.000000 3.000000 2.678072 2.000000 3.000000
>> 10 surveys for 5260 MHz: 3.000000 2.000000 3.000000 3.000000 3.000000
>> 3.000000 2.000000 2.678072 2.000000 2.678072
>> 10 surveys for 5280 MHz: 3.000000 1.415037 3.000000 1.415037 1.678072
>> 2.000000 1.245112 3.000000 3.000000 2.678072
>> 10 surveys for 5300 MHz: 3.000000 3.000000 3.000000 1.415037 3.000000
>> 3.000000 3.000000 2.000000 3.000000 3.000000
>> 10 surveys for 5320 MHz: 3.000000 3.000000 3.000000 3.000000 3.000000
>> 2.678072 3.000000 1.415037 3.000000 2.000000
>> 10 surveys for 5500 MHz: -1.000000 -2.000000 -1.000000 -2.321928
>> -1.321928 -1.321928 -1.000000 -2.321928 -1.000000 -2.459432
>> 10 surveys for 5520 MHz: -2.392317 -1.169925 -1.169925 -0.807355
>> -1.906891 -1.169925 -1.169925 -1.169925 -1.700440 -0.807355
>> 10 surveys for 5540 MHz: -1.169925 -2.643856 -1.169925 -2.087463
>> -1.169925 -1.169925 -2.523562 -1.169925 -1.169925 -1.169925
>> 10 surveys for 5560 MHz: -1.169925 -1.169925 -2.643856 -1.169925
>> -1.321928 -1.169925 -1.459432 -1.700440 -2.087463 -1.169925
>> 10 surveys for 5580 MHz: -1.169925 -1.700440 -1.169925 -1.906891
>> -1.321928 -1.169925 -1.169925 -1.169925 -1.169925 -1.169925
>> 10 surveys for 5600 MHz: -1.169925 -1.169925 -1.169925 -2.643856
>> -0.807355 -2.459432 -1.459432 -1.169925 -1.169925 -1.169925
>> 10 surveys for 5620 MHz: -1.169925 -1.321928 -2.087463 -1.169925
>> -1.169925 -1.321928 -0.807355 -2.392317 -1.169925 -1.169925
>> 10 surveys for 5640 MHz: -2.643856 -1.321928 -1.169925 -2.857981
>> -1.169925 -0.584963 -1.169925 -1.169925 -1.169925 -3.643856
>> 10 surveys for 5660 MHz: -2.169925 -1.584963 -2.169925 -2.857981
>> -1.169925 -1.169925 -1.169925 -1.169925 -1.459432 -1.169925
>> 10 surveys for 5680 MHz: -1.169925 -1.169925 -2.643856 -2.700440
>> -1.169925 -1.169925 -1.169925 -1.169925 -0.807355 -1.700440
>> 10 surveys for 5700 MHz: -2.087463 -1.169925 -1.169925 -1.000000
>> -2.459432 -1.169925 -1.169925 -1.169925 -1.169925 -1.169925
>> 2412 MHz: 13.123357
>> 2417 MHz: -inf
>> 2422 MHz: -inf
>> 2427 MHz: -inf
>> 2432 MHz: -inf
>> 2437 MHz: -inf
>> 2442 MHz: -inf
>> 2447 MHz: -inf
>> 2452 MHz: -inf
>> 2457 MHz: -inf
>> 2462 MHz: -inf
>> 2467 MHz: -inf
>> 2472 MHz: -inf
>> 5180 MHz: 1.618622
>> 5200 MHz: 1.671229
>> 5220 MHz: 1.709311
>> 5240 MHz: 2.692318
>> 5260 MHz: 2.635614
>> 5280 MHz: 2.243133
>> 5300 MHz: 2.741504
>> 5320 MHz: 2.709311
>> 5500 MHz: -1.574714
>> 5520 MHz: -1.346398
>> 5540 MHz: -1.544436
>> 5560 MHz: -1.506274
>> 5580 MHz: -1.311873
>> 5600 MHz: -1.438962
>> 5620 MHz: -1.378062
>> 5640 MHz: -1.690221
>> 5660 MHz: -1.609185
>> 5680 MHz: -1.487164
>> 5700 MHz: -1.373637
>> Ideal freq: 2417 MHz
>>
>>
>> The ideal channel is 2417MHz. But there are many interference in 2.4G at my
>> testing place. the result for that channel is -inf.
>
> Right..
>
>> I did not understand the
>> outcome, maybe you can describe about -infinity and why that this result
>> occurs.
>
> Sure, so -inf means the calculation resulted in a value out of bounds
> by the used data type. The issue lies in the wide range of values that
> we run into for analysis in very noisy environments. One alternative I
> considered was to use __float128 instead of long double for the
> interference_factor but I was unable to figure out how to print these
> correctly.
>
>> will it be causing by scanning time for particular channel is too
>> short?
>
> Can you test with the latest ACS patches I posted for hostapd with
> debugging and see the values you get there?
Or you can try to split up the computation by using logarithm
identities as follows:
diff --git a/survey.c b/survey.c
index ef47f95..13defc8 100644
--- a/survey.c
+++ b/survey.c
@@ -274,10 +274,9 @@ static long double
compute_interference_factor(struct freq_survey *survey, __s8
{
long double factor;
- factor = survey->channel_time_busy - survey->channel_time_tx;
- factor /= (survey->channel_time - survey->channel_time_tx);
- factor *= (base_to_power(2, survey->noise - min_noise));
- factor = log2(factor);
+ factor = log2(survey->channel_time_busy - survey->channel_time_tx);
+ factor -= log2(survey->channel_time - survey->channel_time_tx);
+ factor += survey->noise + min_noise;
survey->interference_factor = factor;
Luis
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: problem on ACS
2011-07-25 23:35 ` Luis R. Rodriguez
@ 2011-07-26 0:13 ` Christian Lamparter
2011-07-26 2:21 ` Luis R. Rodriguez
0 siblings, 1 reply; 17+ messages in thread
From: Christian Lamparter @ 2011-07-26 0:13 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: MingAnn Ng, linux-wireless
On Tuesday, July 26, 2011 01:35:07 AM Luis R. Rodriguez wrote:
> On Mon, Jul 25, 2011 at 1:32 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> > On Thu, Jul 21, 2011 at 8:13 PM, MingAnn Ng <devil_eddie01@hotmail.com> wrote:
> >> Hi Luis,
> >>
> >> I am thinking of using the ACS application for channel selection on IBSS
> >> network. I had run a test with the current git. But the result is not so
> >> convincing.
> >>
> >> 10 surveys for 2412 MHz: 11.382248 12.847997 13.223471 13.403065
> >> 13.454694 13.529891 12.556324 13.573309 13.616969 13.645601
> >> 10 surveys for 2417 MHz: 12.678072 10.299560 -inf -inf 9.678072 -inf -inf
> >> -inf -inf -inf
> >> 10 surveys for 2422 MHz: -inf -inf -inf -inf -inf -inf -inf -inf -inf
> >> -inf
> >> 10 surveys for 2427 MHz: -inf -inf 12.192645 -inf -inf -inf -inf -inf
> >> -inf -inf
> >> 10 surveys for 2432 MHz: -inf 9.192645 12.777608 12.192645 12.192645 -inf
> >> 12.192645 -inf 10.093109 12.192645
> >> 10 surveys for 2437 MHz: 11.192645 -inf 11.000000 10.093109 10.093109
> >> 11.192645 -inf 11.192645 -inf -inf
> >> 10 surveys for 2442 MHz: 10.192645 10.093109 -inf 10.061401 11.192645
> >> -inf -inf -inf 11.192645 10.093109
> >> 10 surveys for 2447 MHz: -inf -inf -inf 11.777608 -inf 10.192645 -inf
> >> -inf -inf -inf
> >> 10 surveys for 2452 MHz: 11.192645 -inf -inf 11.192645 -inf -inf -inf
> >> 13.777608 11.337035 10.830075
> >> 10 surveys for 2457 MHz: 10.192645 -inf -inf -inf -inf -inf -inf -inf
> >> -inf -inf
> >> 10 surveys for 2462 MHz: 9.540568 9.192645 10.283793 8.476438 -inf -inf
> >> -inf -inf 10.192645 -inf
> >> 10 surveys for 2467 MHz: -inf -inf -inf -inf -inf -inf 9.752072 -inf -inf
> >> -inf
> >> 10 surveys for 2472 MHz: -inf -inf 10.192645 -inf -inf -inf -inf -inf
> >> 7.714598 -inf
> >> 10 surveys for 5180 MHz: 2.000000 1.830075 1.000000 0.678072 2.000000
> >> 2.000000 2.000000 0.678072 2.000000 2.000000
> >> 10 surveys for 5200 MHz: 2.000000 1.678072 2.000000 2.000000 2.000000
> >> 2.000000 1.678072 2.000000 0.678072 0.678072
> >> 10 surveys for 5220 MHz: 2.000000 1.415037 2.000000 0.000000 2.000000
> >> 2.000000 1.678072 2.000000 2.000000 2.000000
> >> 10 surveys for 5240 MHz: 3.000000 3.000000 3.000000 1.245112 3.000000
> >> 3.000000 3.000000 2.678072 2.000000 3.000000
> >> 10 surveys for 5260 MHz: 3.000000 2.000000 3.000000 3.000000 3.000000
> >> 3.000000 2.000000 2.678072 2.000000 2.678072
> >> 10 surveys for 5280 MHz: 3.000000 1.415037 3.000000 1.415037 1.678072
> >> 2.000000 1.245112 3.000000 3.000000 2.678072
> >> 10 surveys for 5300 MHz: 3.000000 3.000000 3.000000 1.415037 3.000000
> >> 3.000000 3.000000 2.000000 3.000000 3.000000
> >> 10 surveys for 5320 MHz: 3.000000 3.000000 3.000000 3.000000 3.000000
> >> 2.678072 3.000000 1.415037 3.000000 2.000000
> >> 10 surveys for 5500 MHz: -1.000000 -2.000000 -1.000000 -2.321928
> >> -1.321928 -1.321928 -1.000000 -2.321928 -1.000000 -2.459432
> >> 10 surveys for 5520 MHz: -2.392317 -1.169925 -1.169925 -0.807355
> >> -1.906891 -1.169925 -1.169925 -1.169925 -1.700440 -0.807355
> >> 10 surveys for 5540 MHz: -1.169925 -2.643856 -1.169925 -2.087463
> >> -1.169925 -1.169925 -2.523562 -1.169925 -1.169925 -1.169925
> >> 10 surveys for 5560 MHz: -1.169925 -1.169925 -2.643856 -1.169925
> >> -1.321928 -1.169925 -1.459432 -1.700440 -2.087463 -1.169925
> >> 10 surveys for 5580 MHz: -1.169925 -1.700440 -1.169925 -1.906891
> >> -1.321928 -1.169925 -1.169925 -1.169925 -1.169925 -1.169925
> >> 10 surveys for 5600 MHz: -1.169925 -1.169925 -1.169925 -2.643856
> >> -0.807355 -2.459432 -1.459432 -1.169925 -1.169925 -1.169925
> >> 10 surveys for 5620 MHz: -1.169925 -1.321928 -2.087463 -1.169925
> >> -1.169925 -1.321928 -0.807355 -2.392317 -1.169925 -1.169925
> >> 10 surveys for 5640 MHz: -2.643856 -1.321928 -1.169925 -2.857981
> >> -1.169925 -0.584963 -1.169925 -1.169925 -1.169925 -3.643856
> >> 10 surveys for 5660 MHz: -2.169925 -1.584963 -2.169925 -2.857981
> >> -1.169925 -1.169925 -1.169925 -1.169925 -1.459432 -1.169925
> >> 10 surveys for 5680 MHz: -1.169925 -1.169925 -2.643856 -2.700440
> >> -1.169925 -1.169925 -1.169925 -1.169925 -0.807355 -1.700440
> >> 10 surveys for 5700 MHz: -2.087463 -1.169925 -1.169925 -1.000000
> >> -2.459432 -1.169925 -1.169925 -1.169925 -1.169925 -1.169925
> >> 2412 MHz: 13.123357
> >> 2417 MHz: -inf
> >> 2422 MHz: -inf
> >> 2427 MHz: -inf
> >> 2432 MHz: -inf
> >> 2437 MHz: -inf
> >> 2442 MHz: -inf
> >> 2447 MHz: -inf
> >> 2452 MHz: -inf
> >> 2457 MHz: -inf
> >> 2462 MHz: -inf
> >> 2467 MHz: -inf
> >> 2472 MHz: -inf
> >> 5180 MHz: 1.618622
> >> 5200 MHz: 1.671229
> >> 5220 MHz: 1.709311
> >> 5240 MHz: 2.692318
> >> 5260 MHz: 2.635614
> >> 5280 MHz: 2.243133
> >> 5300 MHz: 2.741504
> >> 5320 MHz: 2.709311
> >> 5500 MHz: -1.574714
> >> 5520 MHz: -1.346398
> >> 5540 MHz: -1.544436
> >> 5560 MHz: -1.506274
> >> 5580 MHz: -1.311873
> >> 5600 MHz: -1.438962
> >> 5620 MHz: -1.378062
> >> 5640 MHz: -1.690221
> >> 5660 MHz: -1.609185
> >> 5680 MHz: -1.487164
> >> 5700 MHz: -1.373637
> >> Ideal freq: 2417 MHz
> >>
> >>
> >> The ideal channel is 2417MHz. But there are many interference in 2.4G at my
> >> testing place. the result for that channel is -inf.
> >
> > Right..
> >
> >> I did not understand the
> >> outcome, maybe you can describe about -infinity and why that this result
> >> occurs.
> >
> > Sure, so -inf means the calculation resulted in a value out of bounds
> > by the used data type. The issue lies in the wide range of values that
> > we run into for analysis in very noisy environments. One alternative I
> > considered was to use __float128 instead of long double for the
> > interference_factor but I was unable to figure out how to print these
> > correctly.
> >
> >> will it be causing by scanning time for particular channel is too
> >> short?
> >
> > Can you test with the latest ACS patches I posted for hostapd with
> > debugging and see the values you get there?
>
> Or you can try to split up the computation by using logarithm
> identities as follows:
>
>
> diff --git a/survey.c b/survey.c
> index ef47f95..13defc8 100644
> --- a/survey.c
> +++ b/survey.c
> @@ -274,10 +274,9 @@ static long double
> compute_interference_factor(struct freq_survey *survey, __s8
> {
> long double factor;
>
> - factor = survey->channel_time_busy - survey->channel_time_tx;
> - factor /= (survey->channel_time - survey->channel_time_tx);
> - factor *= (base_to_power(2, survey->noise - min_noise));
> - factor = log2(factor);
> + factor = log2(survey->channel_time_busy - survey->channel_time_tx);
> + factor -= log2(survey->channel_time - survey->channel_time_tx);
> + factor += survey->noise + min_noise;
^^^^^ that "+" should a "-" right?
btw, base_to_power can go as well. [now if only acs would stop freezing]
Regards,
Chr
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: problem on ACS
2011-07-26 0:13 ` Christian Lamparter
@ 2011-07-26 2:21 ` Luis R. Rodriguez
2011-07-26 2:42 ` Luis R. Rodriguez
[not found] ` <COL114-W76260EA23039CA8000DB88A320@phx.gbl>
0 siblings, 2 replies; 17+ messages in thread
From: Luis R. Rodriguez @ 2011-07-26 2:21 UTC (permalink / raw)
To: Christian Lamparter; +Cc: MingAnn Ng, linux-wireless
On Mon, Jul 25, 2011 at 5:13 PM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Tuesday, July 26, 2011 01:35:07 AM Luis R. Rodriguez wrote:
>> On Mon, Jul 25, 2011 at 1:32 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> > On Thu, Jul 21, 2011 at 8:13 PM, MingAnn Ng <devil_eddie01@hotmail.com> wrote:
>> >> Hi Luis,
>> >>
>> >> I am thinking of using the ACS application for channel selection on IBSS
>> >> network. I had run a test with the current git. But the result is not so
>> >> convincing.
>> >>
>> >> 10 surveys for 2412 MHz: 11.382248 12.847997 13.223471 13.403065
>> >> 13.454694 13.529891 12.556324 13.573309 13.616969 13.645601
>> >> 10 surveys for 2417 MHz: 12.678072 10.299560 -inf -inf 9.678072 -inf -inf
>> >> -inf -inf -inf
>> >> 10 surveys for 2422 MHz: -inf -inf -inf -inf -inf -inf -inf -inf -inf
>> >> -inf
>> >> 10 surveys for 2427 MHz: -inf -inf 12.192645 -inf -inf -inf -inf -inf
>> >> -inf -inf
>> >> 10 surveys for 2432 MHz: -inf 9.192645 12.777608 12.192645 12.192645 -inf
>> >> 12.192645 -inf 10.093109 12.192645
>> >> 10 surveys for 2437 MHz: 11.192645 -inf 11.000000 10.093109 10.093109
>> >> 11.192645 -inf 11.192645 -inf -inf
>> >> 10 surveys for 2442 MHz: 10.192645 10.093109 -inf 10.061401 11.192645
>> >> -inf -inf -inf 11.192645 10.093109
>> >> 10 surveys for 2447 MHz: -inf -inf -inf 11.777608 -inf 10.192645 -inf
>> >> -inf -inf -inf
>> >> 10 surveys for 2452 MHz: 11.192645 -inf -inf 11.192645 -inf -inf -inf
>> >> 13.777608 11.337035 10.830075
>> >> 10 surveys for 2457 MHz: 10.192645 -inf -inf -inf -inf -inf -inf -inf
>> >> -inf -inf
>> >> 10 surveys for 2462 MHz: 9.540568 9.192645 10.283793 8.476438 -inf -inf
>> >> -inf -inf 10.192645 -inf
>> >> 10 surveys for 2467 MHz: -inf -inf -inf -inf -inf -inf 9.752072 -inf -inf
>> >> -inf
>> >> 10 surveys for 2472 MHz: -inf -inf 10.192645 -inf -inf -inf -inf -inf
>> >> 7.714598 -inf
>> >> 10 surveys for 5180 MHz: 2.000000 1.830075 1.000000 0.678072 2.000000
>> >> 2.000000 2.000000 0.678072 2.000000 2.000000
>> >> 10 surveys for 5200 MHz: 2.000000 1.678072 2.000000 2.000000 2.000000
>> >> 2.000000 1.678072 2.000000 0.678072 0.678072
>> >> 10 surveys for 5220 MHz: 2.000000 1.415037 2.000000 0.000000 2.000000
>> >> 2.000000 1.678072 2.000000 2.000000 2.000000
>> >> 10 surveys for 5240 MHz: 3.000000 3.000000 3.000000 1.245112 3.000000
>> >> 3.000000 3.000000 2.678072 2.000000 3.000000
>> >> 10 surveys for 5260 MHz: 3.000000 2.000000 3.000000 3.000000 3.000000
>> >> 3.000000 2.000000 2.678072 2.000000 2.678072
>> >> 10 surveys for 5280 MHz: 3.000000 1.415037 3.000000 1.415037 1.678072
>> >> 2.000000 1.245112 3.000000 3.000000 2.678072
>> >> 10 surveys for 5300 MHz: 3.000000 3.000000 3.000000 1.415037 3.000000
>> >> 3.000000 3.000000 2.000000 3.000000 3.000000
>> >> 10 surveys for 5320 MHz: 3.000000 3.000000 3.000000 3.000000 3.000000
>> >> 2.678072 3.000000 1.415037 3.000000 2.000000
>> >> 10 surveys for 5500 MHz: -1.000000 -2.000000 -1.000000 -2.321928
>> >> -1.321928 -1.321928 -1.000000 -2.321928 -1.000000 -2.459432
>> >> 10 surveys for 5520 MHz: -2.392317 -1.169925 -1.169925 -0.807355
>> >> -1.906891 -1.169925 -1.169925 -1.169925 -1.700440 -0.807355
>> >> 10 surveys for 5540 MHz: -1.169925 -2.643856 -1.169925 -2.087463
>> >> -1.169925 -1.169925 -2.523562 -1.169925 -1.169925 -1.169925
>> >> 10 surveys for 5560 MHz: -1.169925 -1.169925 -2.643856 -1.169925
>> >> -1.321928 -1.169925 -1.459432 -1.700440 -2.087463 -1.169925
>> >> 10 surveys for 5580 MHz: -1.169925 -1.700440 -1.169925 -1.906891
>> >> -1.321928 -1.169925 -1.169925 -1.169925 -1.169925 -1.169925
>> >> 10 surveys for 5600 MHz: -1.169925 -1.169925 -1.169925 -2.643856
>> >> -0.807355 -2.459432 -1.459432 -1.169925 -1.169925 -1.169925
>> >> 10 surveys for 5620 MHz: -1.169925 -1.321928 -2.087463 -1.169925
>> >> -1.169925 -1.321928 -0.807355 -2.392317 -1.169925 -1.169925
>> >> 10 surveys for 5640 MHz: -2.643856 -1.321928 -1.169925 -2.857981
>> >> -1.169925 -0.584963 -1.169925 -1.169925 -1.169925 -3.643856
>> >> 10 surveys for 5660 MHz: -2.169925 -1.584963 -2.169925 -2.857981
>> >> -1.169925 -1.169925 -1.169925 -1.169925 -1.459432 -1.169925
>> >> 10 surveys for 5680 MHz: -1.169925 -1.169925 -2.643856 -2.700440
>> >> -1.169925 -1.169925 -1.169925 -1.169925 -0.807355 -1.700440
>> >> 10 surveys for 5700 MHz: -2.087463 -1.169925 -1.169925 -1.000000
>> >> -2.459432 -1.169925 -1.169925 -1.169925 -1.169925 -1.169925
>> >> 2412 MHz: 13.123357
>> >> 2417 MHz: -inf
>> >> 2422 MHz: -inf
>> >> 2427 MHz: -inf
>> >> 2432 MHz: -inf
>> >> 2437 MHz: -inf
>> >> 2442 MHz: -inf
>> >> 2447 MHz: -inf
>> >> 2452 MHz: -inf
>> >> 2457 MHz: -inf
>> >> 2462 MHz: -inf
>> >> 2467 MHz: -inf
>> >> 2472 MHz: -inf
>> >> 5180 MHz: 1.618622
>> >> 5200 MHz: 1.671229
>> >> 5220 MHz: 1.709311
>> >> 5240 MHz: 2.692318
>> >> 5260 MHz: 2.635614
>> >> 5280 MHz: 2.243133
>> >> 5300 MHz: 2.741504
>> >> 5320 MHz: 2.709311
>> >> 5500 MHz: -1.574714
>> >> 5520 MHz: -1.346398
>> >> 5540 MHz: -1.544436
>> >> 5560 MHz: -1.506274
>> >> 5580 MHz: -1.311873
>> >> 5600 MHz: -1.438962
>> >> 5620 MHz: -1.378062
>> >> 5640 MHz: -1.690221
>> >> 5660 MHz: -1.609185
>> >> 5680 MHz: -1.487164
>> >> 5700 MHz: -1.373637
>> >> Ideal freq: 2417 MHz
>> >>
>> >>
>> >> The ideal channel is 2417MHz. But there are many interference in 2.4G at my
>> >> testing place. the result for that channel is -inf.
>> >
>> > Right..
>> >
>> >> I did not understand the
>> >> outcome, maybe you can describe about -infinity and why that this result
>> >> occurs.
>> >
>> > Sure, so -inf means the calculation resulted in a value out of bounds
>> > by the used data type. The issue lies in the wide range of values that
>> > we run into for analysis in very noisy environments. One alternative I
>> > considered was to use __float128 instead of long double for the
>> > interference_factor but I was unable to figure out how to print these
>> > correctly.
>> >
>> >> will it be causing by scanning time for particular channel is too
>> >> short?
>> >
>> > Can you test with the latest ACS patches I posted for hostapd with
>> > debugging and see the values you get there?
>>
>> Or you can try to split up the computation by using logarithm
>> identities as follows:
>>
>>
>> diff --git a/survey.c b/survey.c
>> index ef47f95..13defc8 100644
>> --- a/survey.c
>> +++ b/survey.c
>> @@ -274,10 +274,9 @@ static long double
>> compute_interference_factor(struct freq_survey *survey, __s8
>> {
>> long double factor;
>>
>> - factor = survey->channel_time_busy - survey->channel_time_tx;
>> - factor /= (survey->channel_time - survey->channel_time_tx);
>> - factor *= (base_to_power(2, survey->noise - min_noise));
>> - factor = log2(factor);
>> + factor = log2(survey->channel_time_busy - survey->channel_time_tx);
>> + factor -= log2(survey->channel_time - survey->channel_time_tx);
>> + factor += survey->noise + min_noise;
> ^^^^^ that "+" should a "-" right?
Um, I don't see why, for the derivation in detail see;
http://wireless.kernel.org/en/users/Documentation/acs
> btw, base_to_power can go as well.
Yup
> [now if only acs would stop freezing]
Is it freezing with the patch? gdb ./acs
run <args>
Luis
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: problem on ACS
2011-07-26 2:21 ` Luis R. Rodriguez
@ 2011-07-26 2:42 ` Luis R. Rodriguez
[not found] ` <COL114-W76260EA23039CA8000DB88A320@phx.gbl>
1 sibling, 0 replies; 17+ messages in thread
From: Luis R. Rodriguez @ 2011-07-26 2:42 UTC (permalink / raw)
To: Christian Lamparter; +Cc: MingAnn Ng, linux-wireless
On Mon, Jul 25, 2011 at 7:21 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> [now if only acs would stop freezing]
>
> Is it freezing with the patch? gdb ./acs
> run <args>
BTW I think this may because for some channels there is no data yet,
for hostapd I solved this by issuing a scan prior to running the ACS
stuff, this seems to force some data collection. The same can be done
with the acs code but I've been lazy to add the full scan request
command into the code, you can however issues scan manually before
running acs, let me know if that cures your woes, if so then we know
what we need to do. In fact we may want to just do a pasive scan on
each channel instead of an offchannel operation, but we can do that
later.
Luis
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: problem on ACS
[not found] ` <COL114-W76260EA23039CA8000DB88A320@phx.gbl>
@ 2011-07-26 18:21 ` Luis R. Rodriguez
2011-07-26 18:31 ` Christian Lamparter
0 siblings, 1 reply; 17+ messages in thread
From: Luis R. Rodriguez @ 2011-07-26 18:21 UTC (permalink / raw)
To: MingAnn Ng; +Cc: chunkeey, wireless testing
On Mon, Jul 25, 2011 at 7:46 PM, MingAnn Ng <devil_eddie01@hotmail.com> wrote:
> Hi Luis,
>
> this is what I'd got after applying logarithm identities patch that you
> provide:
>
> 2412 MHz: -175.357726
> 2417 MHz: -inf
> 2422 MHz: -inf
> 2427 MHz: -inf
> 2432 MHz: -inf
> 2437 MHz: -inf
> 2442 MHz: -inf
> 2447 MHz: -inf
> 2452 MHz: -inf
> 2457 MHz: -inf
> 2462 MHz: -inf
> 2467 MHz: -inf
> 2472 MHz: -inf
> 5180 MHz: -187.707255
> 5200 MHz: -186.721397
> 5220 MHz: -186.067982
> 5240 MHz: -186.584516
> 5260 MHz: -186.872511
> 5280 MHz: -184.567340
> 5300 MHz: -185.224387
> 5320 MHz: -185.794143
> 5500 MHz: -189.525424
> 5520 MHz: -189.417120
> 5540 MHz: -189.705191
> 5560 MHz: -189.639734
> 5580 MHz: -190.396324
> 5600 MHz: -189.503429
> 5620 MHz: -189.685961
> 5640 MHz: -189.421184
> 5660 MHz: -189.814113
> 5680 MHz: -190.737770
> 5700 MHz: -190.546318
> Ideal freq: 2417 MHz
Hm, as for the new values -- they look very different from what you
had gotten before so the math went wrong somewhere.. gotta revise that
a bit more carefully.
> The result is almost the same as the version before applying the patch. the
> -inf still fall on those channel. and those channel are indeed very busy in
> my lab. Is there any other solution which I can try to get a better result
> out of it?
>
> I haven't try on the latest patch for hostapd which you uploaded. Is the acs
> application work along with hostapd to calculate the interference level?
No, the ACS implementation on hostapd simply uses the internal code
from hostapd so its much easier to write, the acs.git code is
completely independent so adding anything there is just a bit harder,
for example adding a scan prior to the ACS work. Please do try the
hostapd patches to see if you get a good channel, and enable debugging
to see the values you get. We do want to avoid the -inf stuff
completely. Getting that means our data type is not sufficient for our
data. The difficult aspect of this code is that the values range from
fractional values to extremely large values..
Luis
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: problem on ACS
2011-07-26 18:21 ` Luis R. Rodriguez
@ 2011-07-26 18:31 ` Christian Lamparter
2011-07-26 20:19 ` Luis R. Rodriguez
0 siblings, 1 reply; 17+ messages in thread
From: Christian Lamparter @ 2011-07-26 18:31 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: MingAnn Ng, wireless testing
On Tuesday, July 26, 2011 08:21:21 PM Luis R. Rodriguez wrote:
> On Mon, Jul 25, 2011 at 7:46 PM, MingAnn Ng <devil_eddie01@hotmail.com> wrote:
> > Hi Luis,
> >
> > this is what I'd got after applying logarithm identities patch that you
> > provide:
> >
> > 2412 MHz: -175.357726
> > 2417 MHz: -inf
> > 2422 MHz: -inf
> > 2427 MHz: -inf
> > 2432 MHz: -inf
> > 2437 MHz: -inf
> > 2442 MHz: -inf
> > 2447 MHz: -inf
> > 2452 MHz: -inf
> > 2457 MHz: -inf
> > 2462 MHz: -inf
> > 2467 MHz: -inf
> > 2472 MHz: -inf
> > 5180 MHz: -187.707255
> > 5200 MHz: -186.721397
> > 5220 MHz: -186.067982
> > 5240 MHz: -186.584516
> > 5260 MHz: -186.872511
> > 5280 MHz: -184.567340
> > 5300 MHz: -185.224387
> > 5320 MHz: -185.794143
> > 5500 MHz: -189.525424
> > 5520 MHz: -189.417120
> > 5540 MHz: -189.705191
> > 5560 MHz: -189.639734
> > 5580 MHz: -190.396324
> > 5600 MHz: -189.503429
> > 5620 MHz: -189.685961
> > 5640 MHz: -189.421184
> > 5660 MHz: -189.814113
> > 5680 MHz: -190.737770
> > 5700 MHz: -190.546318
> > Ideal freq: 2417 MHz
>
> Hm, as for the new values -- they look very different from what you
> had gotten before so the math went wrong somewhere.. gotta revise that
> a bit more carefully.
well, take a close look at the patch.
> - factor *= (base_to_power(2, survey->noise - min_noise));
> + factor += survey->noise + min_noise;
In the original version, you substracted the min band noise from the
channel. Whereas now you add them together.
> > The result is almost the same as the version before applying the patch. the
> > -inf still fall on those channel. and those channel are indeed very busy in
> > my lab. Is there any other solution which I can try to get a better result
> > out of it?
> >
> > I haven't try on the latest patch for hostapd which you uploaded. Is the acs
> > application work along with hostapd to calculate the interference level?
>
> No, the ACS implementation on hostapd simply uses the internal code
> from hostapd so its much easier to write, the acs.git code is
> completely independent so adding anything there is just a bit harder,
> for example adding a scan prior to the ACS work. Please do try the
> hostapd patches to see if you get a good channel, and enable debugging
> to see the values you get. We do want to avoid the -inf stuff
> completely. Getting that means our data type is not sufficient for our
> data. The difficult aspect of this code is that the values range from
> fractional values to extremely large values..
well, if you do a [active] scan. channel_time_tx + channel_time_busy will
definetly not be "zero". Maybe we can get away by adding some threshold
cuts-offs. At least this would fix the -inf.
+ factor = log2(max(1, survey->channel_time_busy - survey->channel_time_tx));
+ factor -= log2(max(1, survey->channel_time - survey->channel_time_tx));
[However, we could also ignore channel surveys with result in a -inf]
Regards,
Chr
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: problem on ACS
2011-07-26 18:31 ` Christian Lamparter
@ 2011-07-26 20:19 ` Luis R. Rodriguez
[not found] ` <COL114-W2204F3FA55EF4C0D20D0C58A350@phx.gbl>
0 siblings, 1 reply; 17+ messages in thread
From: Luis R. Rodriguez @ 2011-07-26 20:19 UTC (permalink / raw)
To: Christian Lamparter; +Cc: MingAnn Ng, wireless testing
On Tue, Jul 26, 2011 at 11:31 AM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Tuesday, July 26, 2011 08:21:21 PM Luis R. Rodriguez wrote:
>
>> Hm, as for the new values -- they look very different from what you
>> had gotten before so the math went wrong somewhere.. gotta revise that
>> a bit more carefully.
>
> well, take a close look at the patch.
>
>> - factor *= (base_to_power(2, survey->noise - min_noise));
>> + factor += survey->noise + min_noise;
>
> In the original version, you substracted the min band noise from the
> channel. Whereas now you add them together.
Ah yes, my documentation was just off, and that is correct as the
original intention was to use the noise as an amplifier of of the
computed values of "business". In this case we first get the min noise
of the band and then get the delta between the observed noise and the
min. This ensured that the amplification factor here would yield 1 as
2^0 is 1, and then really high values where the delta was higher.
>> > The result is almost the same as the version before applying the patch. the
>> > -inf still fall on those channel. and those channel are indeed very busy in
>> > my lab. Is there any other solution which I can try to get a better result
>> > out of it?
>> >
>> > I haven't try on the latest patch for hostapd which you uploaded. Is the acs
>> > application work along with hostapd to calculate the interference level?
>>
>> No, the ACS implementation on hostapd simply uses the internal code
>> from hostapd so its much easier to write, the acs.git code is
>> completely independent so adding anything there is just a bit harder,
>> for example adding a scan prior to the ACS work. Please do try the
>> hostapd patches to see if you get a good channel, and enable debugging
>> to see the values you get. We do want to avoid the -inf stuff
>> completely. Getting that means our data type is not sufficient for our
>> data. The difficult aspect of this code is that the values range from
>> fractional values to extremely large values..
>
> well, if you do a [active] scan. channel_time_tx + channel_time_busy will
> definetly not be "zero".
That's fine though, but I do also prefer to avoid TX'ign data, which
is why I used the offchannel operation instead, but we could do
passive scans.
> Maybe we can get away by adding some threshold
> cuts-offs. At least this would fix the -inf.
>
> + factor = log2(max(1, survey->channel_time_busy - survey->channel_time_tx));
> + factor -= log2(max(1, survey->channel_time - survey->channel_time_tx));
Hm, the threshold cut off idea sound great, however the assumption
here is that busy time is always > tx time and active time is also
always > tx time, this should ensure at least a value of 1 is used,
given that we at least have to go offchannel for at least 1ms. What do
you see that would make these values go < 1?
> [However, we could also ignore channel surveys with result in a -inf]
the issue might be more with the values being *too big*, not too
small, so we'd could use a min instead, to ensure we bound our
computation by the data type used, something like:
+ factor = log2(min(2^30, survey->channel_time_busy -
survey->channel_time_tx));
+ factor -= log2(min(2^30, survey->channel_time -
survey->channel_time_tx));
In fact 2^30 is the highest value that fits into long double so lets
stick with that, and since we have an addition I've tested we can add
log2(2^30) + log2(2^30). I've pushed the changes into acs.git and will
now use this same compuation for hostapd and respin those patches.
Luis
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: problem on ACS
[not found] ` <COL114-W2204F3FA55EF4C0D20D0C58A350@phx.gbl>
@ 2011-07-27 20:18 ` Luis R. Rodriguez
2011-07-27 20:55 ` Swaminathan Vasanth
[not found] ` <COL114-W50D316103F96D9ED1310098A340@phx.gbl>
0 siblings, 2 replies; 17+ messages in thread
From: Luis R. Rodriguez @ 2011-07-27 20:18 UTC (permalink / raw)
To: MingAnn Ng, Felix Fietkau; +Cc: chunkeey, wireless testing
On Tue, Jul 26, 2011 at 7:25 PM, MingAnn Ng <devil_eddie01@hotmail.com> wrote:
> Hi all,
>
> I had git the latest push by Luis, and make a quick test with it. the result
> is as below:
>
> 2412 MHz: 20.000000
> 2417 MHz: 7378697629483820665.500000
> 2422 MHz: 6456360425798343085.000000
> 2427 MHz: 7378697629483820668.000000
> 2432 MHz: 5534023222112865508.000000
> 2437 MHz: 922337203685477605.000000
> 2442 MHz: 4611686018427387922.500000
> 2447 MHz: 2767011611056432762.500000
> 2452 MHz: 2767011611056432763.250000
> 2457 MHz: 2767011611056432762.500000
> 2462 MHz: 3689348814741910340.000000
> 2467 MHz: 7378697629483820664.000000
> 2472 MHz: 8301034833169298245.500000
> 5180 MHz: 8.700000
> 5200 MHz: 9.900000
> 5220 MHz: 10.900000
> 5240 MHz: 10.500000
> 5260 MHz: 10.800000
> 5280 MHz: 12.000000
> 5300 MHz: 11.900000
> 5320 MHz: 10.900000
> 5500 MHz: 6.800000
> 5520 MHz: 8.000000
> 5540 MHz: 6.700000
> 5560 MHz: 6.800000
> 5580 MHz: 6.900000
> 5600 MHz: 2.100000
> 5620 MHz: 5.900000
> 5640 MHz: 6.000000
> 5660 MHz: 6.700000
> 5680 MHz: 6.900000
> 5700 MHz: 6.600000
> Ideal freq: 5600 MHz
>
> The result is more convincing than the previous version without any -inf
> values.
Yay but yeah those really high values are a bit strange, can you try
compiling ACS with VERBOSE=1, you can do this as follows:
export CFLAGS=-DVERBOSE=1
make V=1
You should see DVERBOSE=1 in the cc lines.
As for the output, you will now see verbose details of each survey,
stuff that into a file and inspect it and see why the values for the
interference factor are so high. For example I get:
10 surveys for 5320 MHz:
Survey 1 from wlan0:
noise: -112 dBm
channel active time: 30 ms
channel busy time: 6 ms
channel receive time: 0 ms
channel transmit time: 0 ms
interference factor: 3.000000
Survey 2 from wlan0:
noise: -112 dBm
channel active time: 13 ms
channel busy time: 6 ms
channel receive time: 0 ms
channel transmit time: 0 ms
interference factor: 4.000000
Survey 3 from wlan0:
noise: -112 dBm
channel active time: 13 ms
channel busy time: 6 ms
channel receive time: 0 ms
channel transmit time: 0 ms
interference factor: 4.000000
... etc...
> The above survey is made by the radio channel set to 2412MHz.
> When I do a survey when I'd set the channel to 5180MHz, The result is shown
> below:
>
> 2412 MHz: 17.000000
> 2417 MHz: 17.300000
> 2422 MHz: 15.200000
> 2427 MHz: 17.500000
> 2432 MHz: 17.800000
> 2437 MHz: 16.700000
> 2442 MHz: 15.800000
> 2447 MHz: 14.000000
> 2452 MHz: 15.500000
> 2457 MHz: 14.200000
> 2462 MHz: 14.100000
> 2467 MHz: 12.500000
> 2472 MHz: 15.500000
> 5180 MHz: 7.900000
> 5200 MHz: 9223372036854775814.000000
> 5220 MHz: 9223372036854775814.000000
> 5240 MHz: 9223372036854775815.000000
> 5260 MHz: 9223372036854775814.000000
> 5280 MHz: 7378697629483820653.500000
> 5300 MHz: 8301034833169298234.500000
> 5320 MHz: 7378697629483820653.500000
> 5500 MHz: 9223372036854775810.000000
> 5520 MHz: 9223372036854775809.000000
> 5540 MHz: 9223372036854775811.000000
> 5560 MHz: 9223372036854775809.000000
> 5580 MHz: 9223372036854775811.000000
> 5600 MHz: 9223372036854775811.000000
> 5620 MHz: 9223372036854775810.000000
> 5640 MHz: 9223372036854775811.000000
> 5660 MHz: 9223372036854775810.000000
> 5680 MHz: 9223372036854775811.000000
> 5700 MHz: 9223372036854775810.000000
> Ideal freq: 5180 MHz
>
> the result for 5GHz band showing a much higher interference factor than the
> previous scan with channel set to 2412MHz, and the factor value for 2.4GHz
> is much lower.
Interesting -- the only explanation I have for this is the way the
driver does calibration when on a channel, and this being affected
somehow. More review of the actual survey details for each channel
would help here. Try to inspect it and see why the values are so big.
The different results based on what channel you are set should be
corrected, just not sure yet how. If we use a passive scan I wonder if
we'd get more consistent results -- likely not given that calibration
would depend on your currently operating channel...
> Is this a normal outcome since this is a off-channel survey?
Nope, for example, when I do the same thing you did, first with the
card set to 2412 MHz:
2412 MHz: 11.100000
2417 MHz: 10.100000
2422 MHz: 10.000000
2427 MHz: 9.800000
2432 MHz: 10.000000
2437 MHz: 10.100000
2442 MHz: 8.800000
2447 MHz: 10.200000
2452 MHz: 9.000000
2457 MHz: 10.000000
2462 MHz: 9.600000
5180 MHz: 1.800000
5200 MHz: 1.700000
5220 MHz: 2.700000
5240 MHz: 2.700000
5260 MHz: 2.800000
5280 MHz: 3.900000
5300 MHz: 2.600000
5320 MHz: 3.800000
5745 MHz: -3.000000
5765 MHz: 0.300000
5785 MHz: 0.800000
5805 MHz: -0.200000
5825 MHz: -1.500000
Ideal freq: 5745 MHz
And then if I tune it to 5745 MHz:
2412 MHz: 11.200000
2417 MHz: 9.900000
2422 MHz: 9.900000
2427 MHz: 9.600000
2432 MHz: 10.100000
2437 MHz: 10.100000
2442 MHz: 9.000000
2447 MHz: 9.800000
2452 MHz: 8.900000
2457 MHz: 10.000000
2462 MHz: 10.000000
5180 MHz: 1.800000
5200 MHz: 1.900000
5220 MHz: 2.900000
5240 MHz: 2.800000
5260 MHz: 2.700000
5280 MHz: 3.600000
5300 MHz: 2.600000
5320 MHz: 3.800000
5745 MHz: -3.000000
5765 MHz: 0.800000
5785 MHz: 0.700000
5805 MHz: 0.800000
5825 MHz: -1.100000
Ideal freq: 5745 MHz
What 802.11 card do you have (dmesg | grep ath; and lspci output) ? I
have an AR9280. I also know Felix has been telling me he has some
enhancements to noise floor computation in his queue for ath9k, these
might help here too.
Luis
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: problem on ACS
2011-07-27 20:18 ` Luis R. Rodriguez
@ 2011-07-27 20:55 ` Swaminathan Vasanth
2011-07-27 21:00 ` Luis R. Rodriguez
[not found] ` <COL114-W50D316103F96D9ED1310098A340@phx.gbl>
1 sibling, 1 reply; 17+ messages in thread
From: Swaminathan Vasanth @ 2011-07-27 20:55 UTC (permalink / raw)
To: linux-wireless
Hi all,
@ MingAnn Ng > If you increase the value for acs_num_req_surveys and
acs_roc_duration_ms, you will not get -inf as the interference value. I faced
this problem initially, but with more number of surveys ACS actually picks the
best channel.
@ Luis > I got convincing results on Channel selection. I also cross verified
the selected channel and the channels used by the nearby AP's through Kismet.
With 9 AP's using different channel, ACS selected the channel which was least
used. Great Work Luis !
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: problem on ACS
2011-07-27 20:55 ` Swaminathan Vasanth
@ 2011-07-27 21:00 ` Luis R. Rodriguez
0 siblings, 0 replies; 17+ messages in thread
From: Luis R. Rodriguez @ 2011-07-27 21:00 UTC (permalink / raw)
To: Swaminathan Vasanth; +Cc: linux-wireless
On Wed, Jul 27, 2011 at 1:55 PM, Swaminathan Vasanth
<swaminathanvasanth.r@gmail.com> wrote:
>
> Hi all,
> @ MingAnn Ng > If you increase the value for acs_num_req_surveys and
> acs_roc_duration_ms, you will not get -inf as the interference value. I faced
> this problem initially, but with more number of surveys ACS actually picks the
> best channel.
> @ Luis > I got convincing results on Channel selection. I also cross verified
> the selected channel and the channels used by the nearby AP's through Kismet.
> With 9 AP's using different channel, ACS selected the channel which was least
> used. Great Work Luis !
Wow, awesome, thanks for the verification of the work :) truly the
implementation was just a rush job for an "intermediary" solution for
people who want ACS until we get Spectral Scan ACS support upstream.
Glad its working out as such.
Luis
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: problem on ACS
[not found] ` <COL114-W54CACDD9B23D044E0916368A370@phx.gbl>
@ 2011-07-29 20:50 ` Luis R. Rodriguez
2011-07-30 11:17 ` Christian Lamparter
0 siblings, 1 reply; 17+ messages in thread
From: Luis R. Rodriguez @ 2011-07-29 20:50 UTC (permalink / raw)
To: MingAnn Ng; +Cc: nbd, chunkeey, wireless testing
On Fri, Jul 29, 2011 at 12:39 AM, MingAnn Ng <devil_eddie01@hotmail.com> wrote:
> Survey 2 from wlan0:
> noise: -84 dBm
> channel active time: 12 ms
> channel busy time: 0 ms
> channel receive time: 0 ms
> channel transmit time: 0 ms
> interference factor: 9223372036854775815.000000
This is caused by log2(0), this if fixed as follows:
diff --git a/src/ap/acs.c b/src/ap/acs.c
index aa5498e..04b1e31 100644
--- a/src/ap/acs.c
+++ b/src/ap/acs.c
@@ -125,7 +125,7 @@ static u64 min(u64 a, u64 b)
*/
static u64 log2_sane(u64 val)
{
- return log2(min(1073741824, val));
+ return return (!val) ? 0 : log2(min(1073741824, val));
}
I'll send a new version of the last patch with this fix, thanks for
reporting this.
Luis
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: problem on ACS
2011-07-29 20:50 ` Luis R. Rodriguez
@ 2011-07-30 11:17 ` Christian Lamparter
2011-07-30 11:29 ` Luis R. Rodriguez
0 siblings, 1 reply; 17+ messages in thread
From: Christian Lamparter @ 2011-07-30 11:17 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: MingAnn Ng, nbd, wireless testing
On Friday 29 July 2011 22:50:54 Luis R. Rodriguez wrote:
> On Fri, Jul 29, 2011 at 12:39 AM, MingAnn Ng <devil_eddie01@hotmail.com> wrote:
> > Survey 2 from wlan0:
> > noise: -84 dBm
> > channel active time: 12 ms
> > channel busy time: 0 ms
> > channel receive time: 0 ms
> > channel transmit time: 0 ms
> > interference factor: 9223372036854775815.000000
>
> This is caused by log2(0), this if fixed as follows:
> diff --git a/src/ap/acs.c b/src/ap/acs.c
> index aa5498e..04b1e31 100644
> --- a/src/ap/acs.c
> +++ b/src/ap/acs.c
> @@ -125,7 +125,7 @@ static u64 min(u64 a, u64 b)
> */
> static u64 log2_sane(u64 val)
> {
> - return log2(min(1073741824, val));
> + return return (!val) ? 0 : log2(min(1073741824, val));
> }
>
>
> I'll send a new version of the last patch with this fix, thanks for
> reporting this.
Wait a sec... I guess you misunderstood my post about the cut-off.
I meant that you can cut of at the bottom by using log2(max(1, val)).
This ensures that the log2 will always be >= 0 anyway. In fact log2(1) = 0.
Regards,
Chr
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: problem on ACS
2011-07-30 11:17 ` Christian Lamparter
@ 2011-07-30 11:29 ` Luis R. Rodriguez
2011-07-30 15:54 ` Christian Lamparter
0 siblings, 1 reply; 17+ messages in thread
From: Luis R. Rodriguez @ 2011-07-30 11:29 UTC (permalink / raw)
To: Christian Lamparter; +Cc: MingAnn Ng, nbd, wireless testing
On Sat, Jul 30, 2011 at 4:17 AM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> Wait a sec... I guess you misunderstood my post about the cut-off.
> I meant that you can cut of at the bottom by using log2(max(1, val)).
> This ensures that the log2 will always be >= 0 anyway. In fact log2(1) = 0.
I get that now, but my point was that we also had to cap it for a
higher value too. We now restrict the input to values within the data
type and also ensure log2 will always be >= 0.
Luis
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: problem on ACS
2011-07-30 11:29 ` Luis R. Rodriguez
@ 2011-07-30 15:54 ` Christian Lamparter
2011-07-30 18:24 ` Luis R. Rodriguez
0 siblings, 1 reply; 17+ messages in thread
From: Christian Lamparter @ 2011-07-30 15:54 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: MingAnn Ng, nbd, wireless testing
On Saturday 30 July 2011 13:29:52 Luis R. Rodriguez wrote:
> On Sat, Jul 30, 2011 at 4:17 AM, Christian Lamparter
> <chunkeey@googlemail.com> wrote:
> > Wait a sec... I guess you misunderstood my post about the cut-off.
> > I meant that you can cut of at the bottom by using log2(max(1, val)).
> > This ensures that the log2 will always be >= 0 anyway. In fact log2(1) = 0.
>
> I get that now, but my point was that we also had to cap it for a
> higher value too. We now restrict the input to values within the data
> type and also ensure log2 will always be >= 0.
Doesn't acs [not to be confused with cisco acs] use u64 for all input
data? If so, why do we need to restrict those? After all 2^64-1 ms is
still around 584.9 million years.
(BTW: I don't understand the comment of log2_sane.
log2(2^30) + log2(2^30) = 60. so this should work very well
with a long double. Even with just 80-bit, the range goes from
something like 3.65 * 10^-4951 to 1.19 x 10^4932.)
Chr
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: problem on ACS
2011-07-30 15:54 ` Christian Lamparter
@ 2011-07-30 18:24 ` Luis R. Rodriguez
[not found] ` <COL114-W51F297F32C58B7D93C26828A380@phx.gbl>
0 siblings, 1 reply; 17+ messages in thread
From: Luis R. Rodriguez @ 2011-07-30 18:24 UTC (permalink / raw)
To: Christian Lamparter; +Cc: MingAnn Ng, nbd, wireless testing
On Sat, Jul 30, 2011 at 8:54 AM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Saturday 30 July 2011 13:29:52 Luis R. Rodriguez wrote:
>> On Sat, Jul 30, 2011 at 4:17 AM, Christian Lamparter
>> <chunkeey@googlemail.com> wrote:
>> > Wait a sec... I guess you misunderstood my post about the cut-off.
>> > I meant that you can cut of at the bottom by using log2(max(1, val)).
>> > This ensures that the log2 will always be >= 0 anyway. In fact log2(1) = 0.
>>
>> I get that now, but my point was that we also had to cap it for a
>> higher value too. We now restrict the input to values within the data
>> type and also ensure log2 will always be >= 0.
> Doesn't acs [not to be confused with cisco acs] use u64 for all input
> data? If so, why do we need to restrict those? After all 2^64-1 ms is
> still around 584.9 million years.
>
> (BTW: I don't understand the comment of log2_sane.
> log2(2^30) + log2(2^30) = 60. so this should work very well
> with a long double. Even with just 80-bit, the range goes from
> something like 3.65 * 10^-4951 to 1.19 x 10^4932.)
Input data is u64, however interference factor is long double.
Luis
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: problem on ACS
[not found] ` <COL114-W51F297F32C58B7D93C26828A380@phx.gbl>
@ 2011-08-01 18:00 ` Luis R. Rodriguez
0 siblings, 0 replies; 17+ messages in thread
From: Luis R. Rodriguez @ 2011-08-01 18:00 UTC (permalink / raw)
To: MingAnn Ng; +Cc: chunkeey, nbd, wireless testing
On Sun, Jul 31, 2011 at 11:01 PM, MingAnn Ng <devil_eddie01@hotmail.com> wrote:
> Hi Luis,
>
> I have apply the patch which you've provided. the result is shown as below:
>
> channel=1
> 2412 MHz: 12.600000
> 2417 MHz: 9.900000
> 2422 MHz: 11.300000
> 2427 MHz: 11.200000
> 2432 MHz: 13.600000
> 2437 MHz: 11.800000
> 2442 MHz: 12.300000
> 2447 MHz: 11.600000
> 2452 MHz: 11.300000
> 2457 MHz: 12.100000
> 2462 MHz: 10.100000
> 2467 MHz: 10.800000
> 2472 MHz: 11.100000
> 5180 MHz: 1.600000
> 5200 MHz: 2.400000
> 5220 MHz: 3.000000
> 5240 MHz: 3.200000
> 5260 MHz: 2.900000
> 5280 MHz: 4.100000
> 5300 MHz: 3.700000
> 5320 MHz: 3.000000
> 5500 MHz: 0.100000
> 5520 MHz: -0.100000
> 5540 MHz: -0.300000
> 5560 MHz: -1.100000
> 5580 MHz: -1.200000
> 5600 MHz: -1.200000
> 5620 MHz: -2.400000
> 5640 MHz: -1.000000
> 5660 MHz: -1.300000
> 5680 MHz: -1.200000
> 5700 MHz: -0.300000
> Ideal freq: 5620 MHz
>
> channel=36
> 2412 MHz: 12.300000
> 2417 MHz: 9.900000
> 2422 MHz: 11.700000
> 2427 MHz: 12.200000
> 2432 MHz: 14.300000
> 2437 MHz: 13.000000
> 2442 MHz: 12.900000
> 2447 MHz: 13.300000
> 2452 MHz: 11.500000
> 2457 MHz: 12.100000
> 2462 MHz: 12.200000
> 2467 MHz: 11.600000
> 2472 MHz: 11.100000
> 5180 MHz: 3.800000
> 5200 MHz: 2.000000
> 5220 MHz: 2.100000
> 5240 MHz: 3.200000
> 5260 MHz: 2.200000
> 5280 MHz: 3.000000
> 5300 MHz: 2.500000
> 5320 MHz: 1.900000
> 5500 MHz: -0.800000
> 5520 MHz: -0.700000
> 5540 MHz: -0.800000
> 5560 MHz: -1.600000
> 5580 MHz: -2.000000
> 5600 MHz: -1.700000
> 5620 MHz: -2.700000
> 5640 MHz: -1.800000
> 5660 MHz: -1.800000
> 5680 MHz: -1.900000
> 5700 MHz: -1.000000
> Ideal freq: 5620 MHz
>
> As you can see, the value of the interference factor is smaller than the
> last case.
>
> Is it a problem when the interference factor has a slight increment when it
> scan the assigned channel?
It could be related to the calibration runs that take effect upon
channel changes with the driver. To account for this I increased the
offcannel time on the hostapd patches but did not do this on the
standalone acs.git tree for the acs tool. I've committed a change for
this and pushed it out. Please test it.
Luis
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2011-08-01 18:00 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <COL114-W9CEFD4E7F3803005186F98A4F0@phx.gbl>
[not found] ` <COL114-W59BDCD7915EEDAF4BEE71A8A4E0@phx.gbl>
2011-07-25 20:32 ` problem on ACS Luis R. Rodriguez
2011-07-25 23:35 ` Luis R. Rodriguez
2011-07-26 0:13 ` Christian Lamparter
2011-07-26 2:21 ` Luis R. Rodriguez
2011-07-26 2:42 ` Luis R. Rodriguez
[not found] ` <COL114-W76260EA23039CA8000DB88A320@phx.gbl>
2011-07-26 18:21 ` Luis R. Rodriguez
2011-07-26 18:31 ` Christian Lamparter
2011-07-26 20:19 ` Luis R. Rodriguez
[not found] ` <COL114-W2204F3FA55EF4C0D20D0C58A350@phx.gbl>
2011-07-27 20:18 ` Luis R. Rodriguez
2011-07-27 20:55 ` Swaminathan Vasanth
2011-07-27 21:00 ` Luis R. Rodriguez
[not found] ` <COL114-W50D316103F96D9ED1310098A340@phx.gbl>
[not found] ` <COL114-W54CACDD9B23D044E0916368A370@phx.gbl>
2011-07-29 20:50 ` Luis R. Rodriguez
2011-07-30 11:17 ` Christian Lamparter
2011-07-30 11:29 ` Luis R. Rodriguez
2011-07-30 15:54 ` Christian Lamparter
2011-07-30 18:24 ` Luis R. Rodriguez
[not found] ` <COL114-W51F297F32C58B7D93C26828A380@phx.gbl>
2011-08-01 18:00 ` Luis R. Rodriguez
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).