On Mon, Jul 25, 2011 at 7:46 PM, MingAnn Ng <[email protected]> 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
On Tuesday, July 26, 2011 08:21:21 PM Luis R. Rodriguez wrote:
> On Mon, Jul 25, 2011 at 7:46 PM, MingAnn Ng <[email protected]> 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
On Tue, Jul 26, 2011 at 11:31 AM, Christian Lamparter
<[email protected]> 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