[Tinyos-devel] mica* TimerM

Samuel Madden madden at csail.mit.edu
Tue Aug 10 10:09:39 PDT 2004


Well -- there may be other code that relies on 
Timer.set(TIMER_ONE_SHOT,1) firing an event within 1 or 2 ms, which 
won't work anymore.  This patch seems dangerous, and I think probably 
means someone should look through places where things like the code Joe 
shows are used to see if anything breaks.

The advantage of returning fail is that things that depend on being 
able to get timer events in less than 5 ms just wont work any more, 
rather than displaying flaky or incorrect behavior.

-Sam

On Aug 10, 2004, at 1:02 PM, Joe Polastre wrote:

> I don't think we should return FAIL (for example, this breaks some 
> things,
> like low power listening).  In LPL, we call Timer.set(TIMER_ONE_SHOT, 
> 1) to
> get an event in task context at some point around 1ms later in time.  
> By
> changing the semantics to FAIL, we have to rewrite that LPL code (and 
> I'm
> sure there's other code that does the same hack)
>
> -Joe
>
> -----Original Message-----
> From: tinyos-devel-bounces at Millennium.Berkeley.EDU
> [mailto:tinyos-devel-bounces at Millennium.Berkeley.EDU] On Behalf Of 
> Samuel
> Madden
> Sent: Tuesday, August 10, 2004 8:03 AM
> To: David Moore
> Cc: Matt Welsh; 'TinyOS-Devel list'
> Subject: Re: [Tinyos-devel] mica* TimerM
>
> Thanks for the patch, David.
>
> Seems like we should return FAIL for attempts to register Timers that
> are too fast.
>
> Also, w.r.t. TinyOS being full of overflow errors -- the issue that
> it's pretty easy to write an application that causes the Task queue to
> overflow, whether or not the OS is complicit in that.  My suggestion
> was a way to help application developers understand what's going
> on/going wrong with their programs.
>
> -Sam
>
> On Aug 10, 2004, at 10:40 AM, David Moore wrote:
>
>> Here's the snippet of the patch in question:
>>
>>     static void adjustInterval() {
>>         uint8_t i, val = maxTimerInterval;
>>         if ( mState) {
>>             for (i=0;i<NUM_TIMERS;i++) {
>>                 if ((mState&(0x1L<<i)) && (mTimerList[i].ticksLeft 
>> <val
>> )) {
>>                     val = mTimerList[i].ticksLeft;
>>                 }
>>              }
>> +
>> +            /* DCM: If the interval is set to be less than the 
>> current
>> +             * counter value, the timer will count an extra 256 ticks
>> before
>> +             * hitting the interrupt.  Thus, we check for this
>> condition
>> +             * and avoid it. */
>> +            i = call Clock.readCounter() + 5;
>> +            if (val < i)
>> +                val = i;
>> +
>>              atomic {
>>                 mInterval =  val;
>>                 call Clock.setInterval(mInterval);
>>                 setIntervalFlag = 0;
>>             }
>>
>>         } else {
>>             atomic {
>>               mInterval=maxTimerInterval;
>>               call Clock.setInterval(mInterval);
>>               setIntervalFlag = 0;
>>             }
>>         }
>>         call PowerManagement.adjustPower();
>>     }
>>
>>
>> It's a very simple error check to avoid timer wrap around, but it does
>> effectively reduce the maximum rate of the timer.  Note that the "5" 
>> is
>> an arbitrary decision on my part.  I believe it could be safely 
>> lowered
>> to "3" without ill effect, but any lower than that will likely risk
>> wrap
>> around.  Note that we can still check for any timers faster than 333 
>> Hz
>> when the application creates them and return FAIL if necessary.
>>
>> In terms of the rest of TinyOS, I have done fairly extensive
>> stress-testing to find task queue overflow issues, and there were only
>> two main problems:  TimerM.nc and one bug in the CC1000 stack.  So 
>> it's
>> not like TinyOS is full of these bugs.
>>
>> Regards,
>>
>> David
>>
>> On Tue, 2004-08-10 at 09:03, Samuel Madden wrote:
>>> I tend to agree with Matt that rate-limiting at some arbitrary level
>>> doesn't necessarily help.
>>>
>>> I think it would help to see the code -- what does Timer do when you
>>> request a timer that fires faster than 5ms? Silently adjust the timer
>>> to 5ms? Return FAIL?  The latter, combined with careful documentation
>>> and lots of TOSSIM debug messages seems vastly preferable.
>>>
>>> Is this a clock-speed dependent issue?  Have we tested it on the
>>> Mica2Dots?
>>>
>>> Although it sounds like there is some unpleasant wrap-around issue
>>> that
>>> David is trying to avoid here besides the task-queue overflow issues
>>> Phil mentioned, we have done nothing in the rest of TinyOS to prevent
>>> things like task-queue overflow, which can lead to equally (if not
>>> more) insidious failures.  Not that this is a logical argument 
>>> against
>>> fixing this issue, but it seems like we might want to think about how
>>> we can make these complexities and failure modes more visible, rather
>>> than silently failing and burying more complexity in TinyOS -- e.g.,
>>> we
>>> could create a "purify" target that you could compile against which
>>> would make things like task-queue overflow and unexpected timer
>>> overflow (which sounds detectable, at some code overhead) cause the
>>> program to fail-stop and turn on the LEDS in a specific pattern.
>>>
>>> -Sam
>>>
>>> On Aug 10, 2004, at 7:01 AM, Matt Welsh wrote:
>>>
>>>> On Mon, 2004-08-09 at 23:36, David Moore wrote:
>>>>> With the current architecture of TimerM.nc, a maximum timer
>>>>> frequency
>>>>> of
>>>>> 333 Hz should be reasonably stable, but I would go no higher than
>>>>> that.
>>>>
>>>> The question is - what does this depend on? What do you mean by
>>>> "reasonably stable"? Have you actually measured this? How does this
>>>> depend on the code in the Timer.fired() handler? What happens on a
>>>> different CPU platform?
>>>>
>>>> I agree that there is a tradeoff here, but I'm not sure that 
>>>> limiting
>>>> the timer rate arbitrarily actually fixes the problem, since the
>>>> effective limit seems to depend on many things. On the other hand,
>>>> documenting the practical limits for a no-op timer handler on each
>>>> platform probably makes sense.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Tinyos-devel mailing list
>>>> Tinyos-devel at Millennium.Berkeley.EDU
>>>> http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-devel
>>>
>>> _______________________________________________
>>> Tinyos-devel mailing list
>>> Tinyos-devel at Millennium.Berkeley.EDU
>>> http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-devel
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at Millennium.Berkeley.EDU
> http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-devel



More information about the Tinyos-devel mailing list