* 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
[parent not found: <COL114-W76260EA23039CA8000DB88A320@phx.gbl>]
* 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
[parent not found: <COL114-W2204F3FA55EF4C0D20D0C58A350@phx.gbl>]
* 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
[parent not found: <COL114-W50D316103F96D9ED1310098A340@phx.gbl>]
[parent not found: <COL114-W54CACDD9B23D044E0916368A370@phx.gbl>]
* 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
[parent not found: <COL114-W51F297F32C58B7D93C26828A380@phx.gbl>]
* 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).