[Tinyos-devel] handling FTSP packets with errors

Miklos Maroti mmaroti at math.u-szeged.hu
Fri Mar 6 16:08:26 PST 2009


Phil, I think your fix and analysis is correct. Miklos

On Fri, Mar 6, 2009 at 7:08 PM, Philip Levis <pal at cs.stanford.edu> wrote:
>
> 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
>
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>



More information about the Tinyos-devel mailing list