[Tinyos-devel] DutyCycle vs SleepInterval
Razvan Musaloiu-E.
razvanm at cs.jhu.edu
Fri Apr 3 14:48:02 PDT 2009
Hi!
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].
[1] http://hinrg.cs.jhu.edu/git/?p=razvanm/tinyos-2.x.git
[2] http://hinrg.cs.jhu.edu/git/?p=razvanm/tinyos-2.x.git;a=blob;f=apps/tests/TestNetworkLpl/Globals.h;h=b6352d80c93b345394f443973c1d8f0f41e30478;hb=f056e67c48f427d6751b069d581a7300d3f9f9df
--
Razvan ME
> 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
>>
>
More information about the Tinyos-devel
mailing list