On Tue, Jul 26, 2011 at 11:31 AM, Christian Lamparter <chunkeey@xxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
