[Tinyos-commits] CVS: tinyos-1.x/tos/platform/pc hpl.c,1.16,1.17

[Phil Levis]

Update of /cvsroot/tinyos/tinyos-1.x/tos/platform/pc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv32020

Modified Files:
	hpl.c 
Log Message:
Incorporated David Tucker's suggested bug fix in hpl.c.

The problem observed was that timers in TOSSIM sometimes fire
early. This happened because of a bad interaction between how TOSSIM
emulates the hardware counter and how it handles time events.

TOSSIM calculates the hardware counter value based on when the counter
last reset. This happens when a timer compare event goes off (the
counter is equal to the compare value). TOSSIM can't really remove events
once they are in the queue; if a program changes the compare value, then
TOSSIM invalidates the current compare event (sets its valid field to 0)
and inserts a new one. When it pulls an invalidated event off the queue,
it deallocates it and does not trigger the compare event.

The bug was that TOSSIM was setting the clock reset time on
invalidated events. Imagine two events, A and B, going forward in time
from left to right:

A1                    B1   A2               B2
Time -------------->

When A fires the first time, A1, it re-enqueues itself (A2). However,
before A2 occurs, the system changes the compare register so the timer
event should occur at time B1: it allocates a new event B, invalidates
A, and puts B on the queue. When B1 arrives, B re-enqueues itself as B2.

When A2 is pulled off the queue, no compare event occurs, but TOSSIM's
notion of when the counter last reset is set to time A2 (this is the
bug). Then, if the TinyOS timer inspects the counter value, it will
think that it is smaller than it actually is (it thinks B2 will fire
later than it will, at time B2 + (A2 - B1)). If the system needs a
timer that would fire in the interval of (B2, (B2 + (A2 - B1))), that
is, AFTER B2 but BEFORE what it incorrectly *thinks* is B2, then it
will incorrectly reset the compare value, causing the next timer to
fire (A2 - B1) early.

The simple solution (and correct behavior) is to not set the last
reset time unless the timer event is valid.





Index: hpl.c
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/tos/platform/pc/hpl.c,v
retrieving revision 1.16
retrieving revision 1.17
diff -C2 -d -r1.16 -r1.17
*** hpl.c	29 Oct 2004 02:08:21 -0000	1.16
--- hpl.c	22 Jun 2005 00:27:57 -0000	1.17
***************
*** 160,164 ****
    clock_tick_data_t* data = (clock_tick_data_t*)event->data;
    atomic TOS_LOCAL_ADDRESS = (short)(event->mote & 0xffff);
-   setTime[NODE_NUM] = tos_state.tos_time; // Overflow to zero
    
    if (TOS_LOCAL_ADDRESS != event->mote) {
--- 160,163 ----
***************
*** 173,176 ****
--- 172,176 ----
      }
  
+     setTime[NODE_NUM] = tos_state.tos_time;
      event->time = event->time + data->interval;
      queue_insert_event(queue, event);