[net2-wg] problem with the timer that controls routing beacon rate in CtpRoutingEngineP.nc

[Omprakash Gnawali]

On Tue, Mar 18, 2008 at 4:25 PM, Philip Levis <pal at cs.stanford.edu> wrote:
>
> On Tue, 2008-03-18 at 14:29 -0800, Omprakash Gnawali wrote:
>  > >  > 2. Triggered route updates using the same timer as Trickle timer. We
>  > >  > thought we would be able to fix this by calling resetInterval()
>  > >  > instead of starting the timer when we need to generate on-demand
>  > >  > beacons. This will ensure that there is only one way to change the
>  > >  > Timer. Unfortunately, this will not work - we want to control how long
>  > >  > to wait until we send a beacon in case of on-demand beacons depending
>  > >  > on the situation (trigger update vs trigger immediate update), not
>  > >  > possible using a single resetInterval() call.
>  > >
>  > >  Why are there two different cases? What is the difference? IIRC, we were
>  > >  originally trying to distinguish beacons that should send soon and
>  > >  beacons that should send NOW. But in the case of trickle, we can just
>  > >  reduce this to beacons that should send NOW and take advantage of the
>  > >  exponential decay. So we send a few extra packets. Let's simplify it.
>  >
>  > Are you saying that reset should always trigger an immediate beacon?
>  > Right now we set the timer to fire at min interval upon reset.
>
>  You should never send an *immediate beacon.* IIRC, even the "immediate"
>  beacon is a 32ms timer. So the trickle interval tau_l should be very
>  small...


If tau_l is 32ms, then we will have the next beacon at 64ms, 128ms,
256ms, 512ms, 1s - it seems like a lot of unnecessary beacons. To
prevent this, my approach would be to reset interval to taul_l = 1s
and specify the first fire time to be 32ms, and when the timer fires
at 32ms, we look at the value of interval and decide to fire at 1s,
and we double it, then fire at 2s, etc.

- om_p