[Tinyos-devel] DutyCycle vs SleepInterval

Fri Apr 3 15:10:11 PDT 2009

On Fri, 3 Apr 2009, Razvan Musaloiu-E. wrote:
> On Fri, 3 Apr 2009, David Moss wrote:
>
> > For reference, the CCxx00 radio stack provides an interface that tells you
> > your average radio duty cycle over the lifetime of your hardware.  Handy
> > function to have for a real deployment, and I recommend an implementation of
> > it in every stack since it's virtually free.  Probably should be a separate
> > interface though. It finds this by accumulating the amount of time the radio
> > has been turned on and dividing that by the total age of your application
> > (using Timer.getNow()).
>
> This counter is indeed very useful. The 'default-lpl' and 'master+lpp'
> heads from my git repository [1] are maintaining the amount the radio is
> on and the amount the time the mote is on in clock ticks. Beside that a
> bunch of other counters (number of CCA checks, number of wakeups, numbers
> of packet send and receive) are also maintained [2].

Agreed. This kind of information is definitely more accurate and probably
more useful for applications.

--
- Konrad Iwanicki.

> > This method gives you a pretty good estimate of your real duty cycle without
> > having to break out any kind of measurement equipment.
> >
> > Adding in a function to tell you how much time it takes to probe the channel
> > isn't very good: you typically need some kind of measurement equipment to
> > figure it out in the first place, and it's never accurate especially after
> > even minor tweaks have been made to the stack.  The value rots when there
> > isn't somebody there to measure it all the time. We tried this method with
> > the setxxxDutyCycle() function, and that's one of the reasons why
> > setDutyCycle() failed and is not accurate at all.
> >
> > -David
> >
> >
> >
> > -----Original Message-----
> > From: tinyos-devel-bounces at millennium.berkeley.edu
> > [mailto:tinyos-devel-bounces at millennium.berkeley.edu] On Behalf Of Konrad
> > Iwanicki
> > Sent: Friday, April 03, 2009 1:57 PM
> > To: tinyos-devel at millennium.berkeley.edu
> > Subject: Re: [Tinyos-devel] DutyCycle vs SleepInterval
> >
> > 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
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >> --
> >> geoffrey werner challen (né werner-allen) :: 617.694.7261 ::
> >> www.eecs.harvard.edu/~werner
> >>
> >