[Tinyos-devel] Testing FTSP

[Branislav Kusy]

 >> 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;
looking at the counter vs the local time is very useful in finding out 
problems in timestamping (code that records time deep in the MAC layer, 
after receiving SFD interrupt). so i'd include this data as useful.
	
 > 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();
skew_times_1000000 is rarely useful. if you are size limited, i'd swap 
it for local time and counter.

note that if you want to output both local and global timestamp, the 
order must be
 >     report->local_rx_timestamp = rxTimestamp;
 >     report->is_synced = call GlobalTime.local2Global(&rxTimestamp);
 >     report->global_rx_timestamp = rxTimestamp;
as local2Global() converts local rxtimestamp to global time.

 > 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.
yes, this would be very useful to look at. if radio links are terrible, 
it is possible that different roots get elected and tables are flushed, 
which would be a problem. increasing timesync period could be a 
solution? but first, it would be very useful to see the local time vs 
counter graph - there used to be a bug in radio stack which would cause 
wrong association between incoming radio packets and SFD interrupts 
(timestamps are buffered in a FIFO in CC2420ReceiveP.nc). i haven't seen 
it in rc3 testing (about 20 micaz motes running for an hour, single 
hop), but i'd just like to make sure before we start tweaking ftsp.

thanks,
brano