User defined interval scale for trickle algorithm

[oldrich-s]

Is there any reason why you fix the interval scaling of the trickle algorithm to be 2?

I have made custom changes to trickle.c which you can find here:

https://gist.github.com/czb/e6788a682b172f03aeb5c1254239bdeb

basically I removed

static uint32_t nearest_power_of_two(uint32_t x)
{
    uint32_t pow = 1;
    while (pow < (x))
        pow <<= 1;
    return pow;
}

(Is there any reason why you force the limits to be power of two?)

and changed:

uint64_t i_half = trickle->i_relative >> 1;

into

uint64_t i_half = trickle->i_relative / rbc_mesh_trickle_time_scale + 0.5;

and

trickle->i_relative <<= 1;

to

trickle->i_relative = trickle->i_relative * rbc_mesh_trickle_time_scale + 0.5;

where rbc_mesh_trickle_time_scale is just a global float and defaults to 2.0.

It seems to work just fine. Is there anything I should be aware of when doing this? :)

[trond-snekvik]

The interval scaling is aligned with the trickle specification, we hadn't really considered customizing it, as we expect the intervals themselves allow for enough customization for casual users :)

You might still want to keep the i_half to be half of your current interval, as it only determines which part of the current interval is available for the randomized offset of transmissions. It is a separate parameter from the interval increase rate. Nothing wrong with customizing this as well of course.

You should be aware that the nRF51 doesn't have hardware support for floating points, so you might want to profile the execution time of the float operations - it can be pretty high. Also check to see if numbers like 0.5 get treated as doubles, which would cause even more harm to your execution time without much value added. It's safest to define them as 0.5f if you don't explicitly need the extra precision.

Other than this, everything looks good to me :+1:

Is there any reason why you force the limits to be power of two?

It lets us use bitwise and instead of modulo here. We plan to remove this particular restriction for the next release, as the added flexibility is worth the performance hit.

[oldrich-s]

Thank you for your very helpful comments. Here you can see my changes:

https://gist.github.com/czb/e6788a682b172f03aeb5c1254239bdeb/revisions

Basically I changed from float to uint8_t as 0.1 precision should be fine enough and it will probably be faster.