[Tinyos-devel] DutyCycle vs SleepInterval
David Moss
dmm at rincon.com
Fri Apr 3 14:12:16 PDT 2009
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 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/h
> > tml/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