[Tinyos-devel] Testing FTSP

[Omprakash Gnawali]

On Mon, Jul 28, 2008 at 11:36 PM, Branislav Kusy <kusy at stanford.edu> wrote:
>
>
> Omprakash Gnawali wrote:
>>
>> On Mon, Jul 28, 2008 at 11:23 PM, Branislav Kusy <kusy at stanford.edu>
>> wrote:
>>>
>>> Omprakash Gnawali wrote:
>>>>
>>>> I wanted to see if the current version of FTSP in rc3 works well in a
>>>> multihop environment. I modified TestFtsp to send the return value of
>>>> call GlobalTime.local2Global(&rxTimestamp) through UART every 4s and
>>>> plotted the output - time on x-axis and node id on y-axis and (x,y) is
>>>> plotted if the return value is 1 suggesting FTSP is out of sync. If
>>>> FTSP is working well, we expect very few points on this graph. The
>>>> experiment was done on channel 25 on a 56-node TelosB testbed.
>>>>
>>>> Here are the results:
>>>> Default tx power:
>>>> http://enl.usc.edu/~om_p/net2/test-ftsp/ftsp_result1.gif
>>>> tx power = 14: http://enl.usc.edu/~om_p/net2/test-ftsp/ftsp_result2.gif
>>>>
>>>> Is FTSP out of sync too often or not too far off the expected result?
>>>
>>> could i see the full log? (even better, if you could log the whole
>>> test_ftsp_msg_t struct over uart)
>>
>> The logs from current experiment do not contain information other than
>> what is displayed on the graph.
>>
>>> one reason can be (depending on how many hops you have) too high resync
>>> frequency, currently set to 3 seconds (TIMESYNC_RATE in
>>> TestFtsp/Makefile).
>>> we used ~30 sec for large scale tests.
>>
>> I forgot to mention that I commented that line from Makefile so it is
>> using the default of 10s.
>
> these results are really bad, there should be no red crosses after the
> initial synchronization period (first 40-50 seconds). is there a way to

Agree.

> re-run the experiment (first 500s would be enough) while logging the whole
> debug struct(test_ftsp_msg_t)? could i also see the deployment map?

Just so I understand this, I am dividing these attributes into useful
and not useful (log trigger is a periodic timer in my experiment).
Please let me know if you agree:

Not useful:
            report->counter = rcm->counter;
            report->local_rx_timestamp = rxTimestamp;
            report->global_rx_timestamp = rxTimestamp;

Useful:
            report->src_addr = TOS_NODE_ID;
            report->is_synced = call GlobalTime.local2Global(&rxTimestamp);
            report->skew_times_1000000 = (uint32_t)call
TimeSyncInfo.getSkew()*1000000UL;
            report->ftsp_root_addr = call TimeSyncInfo.getRootID();
            report->ftsp_seq = call TimeSyncInfo.getSeqNum();
            report->ftsp_table_entries = call TimeSyncInfo.getNumEntries();

So, it is possible we will get insights on the interpolation table is
getting flushed (if it is getting flushed), some different roots are
getting elected, things like that.

Here is a map of the deployment:
http://enl.usc.edu/projects/tutornet/Tutornet.jpg

I used nodes 1-56.

Thanks.

- om_p