On Fri, Jul 29, 2011 at 12:39 AM, MingAnn Ng <[email protected]> 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
On Sat, Jul 30, 2011 at 4:17 AM, Christian Lamparter
<[email protected]> 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
On Saturday 30 July 2011 13:29:52 Luis R. Rodriguez wrote:
> On Sat, Jul 30, 2011 at 4:17 AM, Christian Lamparter
> <[email protected]> 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
On Sat, Jul 30, 2011 at 8:54 AM, Christian Lamparter
<[email protected]> wrote:
> On Saturday 30 July 2011 13:29:52 Luis R. Rodriguez wrote:
>> On Sat, Jul 30, 2011 at 4:17 AM, Christian Lamparter
>> <[email protected]> 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
On Friday 29 July 2011 22:50:54 Luis R. Rodriguez wrote:
> On Fri, Jul 29, 2011 at 12:39 AM, MingAnn Ng <[email protected]> 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