[Tinyos-devel] handling FTSP packets with errors

[Philip Levis]

On Feb 27, 2009, at 3:11 PM, Omprakash Gnawali wrote:

> If a packet seems inconsistent (ENTRY_THROWOUT_LIMIT), FTSP will not
> only discard that packet, but ignore rest of the packets with the same
> root+sequence number, regardless of the packet origin. The latter
> seems overly aggressive unless there is an evidence that inconsistency
> is correlated in sequence number even across the nodes. If there is no
> evidence of that, it might be better to allow the possibility of
> "good" packets following "bad" packets with the same sequnence number.
> Consider the possibility of running FTSP with TS_TIMER_MODE, there is
> one node with some problem, and due to phase of the timer, this node
> might always send the first "bad" beacon in a neighborhood for every
> sequence number...

I don't think this is a major issue. But there is a bug in FTSP. In  
addNewEntry:

     uint8_t numErrors=0;
     void addNewEntry(TimeSyncMsg *msg)
     {
         int8_t i, freeItem = -1, oldestItem = 0;
         uint32_t age, oldestTime = 0;
         int32_t timeError;

         tableEntries = 0;

         // clear table if the received entry's been inconsistent for  
some time
         timeError = msg->localTime;
         call GlobalTime.local2Global((uint32_t*)(&timeError));
         timeError -= msg->globalTime;
         if( (is_synced() == SUCCESS) &&
             (timeError > ENTRY_THROWOUT_LIMIT || timeError < - 
ENTRY_THROWOUT_LIMIT))
         {
             if (++numErrors>3)
                 clearTable();
         }
         else
             numErrors = 0;

         // Code for adding an entry follows

the bug is that a bad reading is incorporated into the table. So if  
you hear one bad reading (++numErrors), you put it in the table. Then  
subsequent good readings can seem bad. So a bad reading needs to not  
be added. Furthermore, as this code counts the number of entries in  
the table, you need to move that reset later in the function. The  
function should be:

     uint8_t numErrors=0;
     void addNewEntry(TimeSyncMsg *msg)
     {
         int8_t i, freeItem = -1, oldestItem = 0;
         uint32_t age, oldestTime = 0;
         int32_t timeError;

         // clear table if the received entry's been inconsistent for  
some time
         timeError = msg->localTime;
         call GlobalTime.local2Global((uint32_t*)(&timeError));
         timeError -= msg->globalTime;
         if( (is_synced() == SUCCESS) &&
             (timeError > ENTRY_THROWOUT_LIMIT || timeError < - 
ENTRY_THROWOUT_LIMIT))
         {
             if (++numErrors>3)
                 clearTable();
             return; // Don't incorporate a bad reading
         }

         tableEntries = 0; // Don't reset table size unless you're  
recounting
         numErrors = 0;


Om and I have tested this fix and it makes FTSP maintain  
synchronization much better. Happy to provide experimental data if  
desired.

Phil