[Tinyos-devel] DutyCycle vs SleepInterval

Konrad Iwanicki iwanicki at few.vu.nl
Fri Apr 3 13:57:29 PDT 2009


Hi everybody,

On Fri, 3 Apr 2009, Geoffrey Werner Challen wrote:
> I also vote for sleep interval.
>
> Duty cycle implies some notion of how long the radio is going to be on for
> when it comes on, right?  I never remember how long the check interval is so
> I probably couldn't even compute the duty cycle without scratching my head
> and poring through the code a bit.  Sleep interval as the distance between
> two channel checks seems much more intuitive.  At least to me.

If I can contribute anything to the discussion, I would also vote for
sleep interval. There is one issue, though.

As Geoffrey pointed out, it is difficult to compute the duty cycle without
going through the code to get the check period. However, when you
configure your applications with LPL, you often want to know how
much time checking the channel takes, simply because you want to
understand the performance of the application better.

However, when you remove the duty-cycle-related functionality from the
interface, the interface completely loses information on how much
time probing the channel takes.

Therefore, perhaps, when removing the duty-cycle related functions (6 in
total), it would be worth to add 1 more function that would return the
time it takes to probe the channel?

Anyway, a person using LPL has to have an idea how it works... But that's
just my opinion.

--
- Konrad.


> On Fri, Apr 3, 2009 at 1:25 AM, Omprakash Gnawali <gnawali at usc.edu> wrote:
>
> > I vote for sleep interval.
> >
> > - om_p
> >
> > On Sun, Jan 11, 2009 at 7:20 AM, Miklos Maroti <mmaroti at math.u-szeged.hu>
> > wrote:
> > > Hi!
> > >
> > > I vote for sleep interval (less portable, but much more predictable)
> > >
> > > Miklos
> > >
> > > On Sat, Jan 10, 2009 at 2:56 AM, Razvan Musaloiu-E. <razvanm at cs.jhu.edu>
> > wrote:
> > >> Hi!
> > >>
> > >> The current LowPowerListening [1] interface contains two sets of
> > >> commands: one using intervals expressing sleep intervals and another one
> > >> using percentages expressing duty-cycles. What I would like to bring
> > into
> > >> discussion is the duty-cycles.
> > >>
> > >> For reference here is the interface:
> > >>
> > >>        interface LowPowerListening {
> > >>          command void setLocalSleepInterval(uint16_t sleepIntervalMs);
> > >>          command uint16_t getLocalSleepInterval();
> > >>          command void setRxSleepInterval(message_t *msg, uint16_t
> > sleepIntervalMs);
> > >>          command uint16_t getRxSleepInterval(message_t *msg);
> > >>
> > >>          command void setLocalDutyCycle(uint16_t dutyCycle);
> > >>          command uint16_t getLocalDutyCycle();
> > >>          command void setRxDutyCycle(message_t *msg, uint16_t
> > dutyCycle);
> > >>          command uint16_t getRxDutyCycle(message_t *msg);
> > >>
> > >>          command uint16_t dutyCycleToSleepInterval(uint16_t dutyCycle);
> > >>          command uint16_t sleepIntervalToDutyCycle(uint16_t
> > sleepInterval);
> > >>        }
> > >>
> > >>
> > >> So for intervals we have 64K possible values. The duty cycles are
> > >> expressed in 1/100 increments so for them we have 10000 possible values.
> > >> For CC2420 these 10000 values actually corresponds only to about 650
> > >> unique sleep intervals.
> > >>
> > >> Another issue is the fact that the duty-cycle is not guarantee. The
> > >> current LPL doesn't track the achieved duty-cycle and dynamically adjust
> > >> the sleep intervals in order to meet a certain one. What happens is a
> > >> fixed sleep interval is picked by translating the duty-cycle to a sleep
> > >> interval using a fixed knowledge about how much the probing should take.
> > >> So basically the semantics is that that duty-cycle will be achieved only
> > >> if there is no traffic and no false wakeups. I find this definition
> > >> cumbersome and not very attractive to work with.
> > >>
> > >> So my questions are: what do people think about this? Do you usually use
> > >> intervals or duty-cycles in your LPL applications? How does sliming down
> > >> the LowPowerInterface to only 4 calls sound? :-)
> > >>
> > >> [1]
> > http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep105.html
> > >>
> > >> All the best!
> > >> Razvan ME
> > >> _______________________________________________
> > >> Tinyos-devel mailing list
> > >> Tinyos-devel at millennium.berkeley.edu
> > >>
> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
> > >>
> > > _______________________________________________
> > > Tinyos-devel mailing list
> > > Tinyos-devel at millennium.berkeley.edu
> > >
> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
> > >
> >
> > _______________________________________________
> > Tinyos-devel mailing list
> > Tinyos-devel at millennium.berkeley.edu
> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
> >
> >
>
>
> --
> geoffrey werner challen (né werner-allen) :: 617.694.7261 ::
> www.eecs.harvard.edu/~werner
>



More information about the Tinyos-devel mailing list