Dear All, Again, thanks to those who replied to me.
I have investigated the issue further and narrowed down the problem. The issue was related to the calculation of the skew in TimeSyncP (so it's the slope of the linear regression). While the computation of the linear regression was perfectly fine (from the C point of view), the actual value of the skew was incorrect. You might recall that this has been already raised in the past ( https://www.millennium.berkeley.edu/pipermail/tinyos-help/2010-November/048878.html) and pretty much the problem was ignored. However, while the previous symptoms suggested that floating point division might be the issue, on TinyOS's google code repo, in Issue 10: Floating Point Arithmetic and FTSP, Philip has explained why this should not be the case - which makes sense. In any case, the issue has persisted ( https://www.millennium.berkeley.edu/pipermail/tinyos-help/2012-July/055155.html), the skew was incorrect and it was not the floating division. Please take a look at the following code from TimeSyncP.nc file, in calculateConversion() function: for(i = 0; i < MAX_ENTRIES; ++i) if( table[i].state == ENTRY_FULL ) { int32_t a = table[i].localTime - newLocalAverage; // a is (xi - x) int32_t b = table[i].timeOffset - newOffsetAverage; // b is (yi - y) localSum += (int64_t)a * a; // Sum of (xi -x)^2 offsetSum += (int64_t)a * b; // Sum of (xi - x)(yi - y) } Everything looks good in the code and the regression is computed as expected. However, while investigating the code further I've noticed that the localSum does not equal to the sum that one would compute offline by summing squares of a. Trying couple of tricks and making more tests I've found no point in digging around this code further as I was always getting incorrect sum. The point was clear: the C code is perfectly valid, the compiled results is not. So I checked my msp430-gcc version which was gcc version 4.5.3 (GCC). I upgraded msp430-gcc to msp430-gcc-4.6.3 from tinyprod and now everything works fine. Bottom line, FTSP does not work with msp430-gcc-4.5.3. With this observation in mind, I would like to ask developers to maybe add a warning/error in FTSP that would inform/prevent others from getting into the same issue and spend time in potential problem investigation. Best, Marcin On Tue, Sep 25, 2012 at 7:25 PM, Marcin Szczodrak <mar...@ieee.org> wrote: > Hi Han Bin, > > Please take a look at the log from one of the tests. This code is printed > from void addNewEntry(TimeSyncMsg *msg) function. As you can see, every > time the number of the table entries (numEntries) is >= 4, the timeError of > new TimeSync message is checked, and it never fits between the limits > of ENTRY_THROWOUT_LIMIT (500). > > The logs are from experiment with 2 motes, each within a distance of ~4 > inches from each other. > > msg->localTime:657714 msg->globalTime:750209 timeError:-92495 > offsetAverage:0 localAverage:0 > msg->localTime:767248 msg->globalTime:767367 timeError:92376 > offsetAverage:92495 localAverage:657714 > msg->localTime:876782 msg->globalTime:876903 timeError:90192 > offsetAverage:46307 localAverage:712481 > msg->localTime:986316 msg->globalTime:986439 timeError:-283317 > offsetAverage:30912 localAverage:767249 > msg->localTime:1095850 msg->globalTime:1095975 timeError:-99916 > offsetAverage:23215 localAverage:822017 > timeError too big > msg->localTime:1205384 msg->globalTime:1205511 timeError:-149120 > offsetAverage:23215 localAverage:822017 > timeError too big > msg->localTime:1314918 msg->globalTime:1315047 timeError:-198325 > offsetAverage:23215 localAverage:822017 > timeError too big > msg->localTime:1424452 msg->globalTime:1424583 timeError:-247530 > offsetAverage:23215 localAverage:822017 > timeError too big - cleanTable > msg->localTime:1533986 msg->globalTime:1534119 timeError:-296735 > offsetAverage:23215 localAverage:822017 > msg->localTime:1643520 msg->globalTime:1643655 timeError:-49204 > offsetAverage:133 localAverage:1533986 > msg->localTime:1753055 msg->globalTime:1753191 timeError:197128 > offsetAverage:134 localAverage:1588753 > msg->localTime:1862589 msg->globalTime:1862727 timeError:-7293 > offsetAverage:135 localAverage:1643522 > msg->localTime:1972123 msg->globalTime:1972263 timeError:-1510611 > offsetAverage:136 localAverage:1698290 > timeError too big > msg->localTime:2081657 msg->globalTime:2081799 timeError:-2114860 > offsetAverage:136 localAverage:1698290 > timeError too big > msg->localTime:2191191 msg->globalTime:2191335 timeError:-2719110 > offsetAverage:136 localAverage:1698290 > timeError too big > msg->localTime:2300725 msg->globalTime:2300871 timeError:-3323359 > offsetAverage:136 localAverage:1698290 > timeError too big - cleanTable > msg->localTime:2410259 msg->globalTime:2410407 timeError:-3927609 > offsetAverage:136 localAverage:1698290 > > > Best, > Marcin > > > On Tue, Sep 25, 2012 at 4:28 AM, LoveYou <pvvinh...@yahoo.com> wrote: > >> Dear Marcin, >> >> Your explanation help me understood more how FTSP implementation works. >> Thank your about this. As your explanation, at the receiver, we get two >> time values: >> msg->globalTime = time_at_sender_when_sender_sent (Call >> TimeSyncAMSend.send) >> msg->localTime = time_at_receiver_when_sender_sent (by calling >> TimeSyncPacket.eventTime(msg)) >> so we get timeOffset = msg->globalTime - msg->localTime; >> And we expect that timeOffset does not vary much for each packet. >> However, I observed that the timeOffset value is very abnormal, it changes >> time to time. Moreover, value of msg->localTime does not correspond to the >> time of the event in receiver's local clock (I get receiver's local clock >> by calling GlobalTime.getLocalTime() to compare with). That is the reason >> why we get the large timeError value in addNewEntry function >> >> timeError = msg->localTime; >> call GlobalTime.local2Global((uint32_t*)(&timeError)); >> timeError -= msg->globalTime; >> >> I'm trying to test many time but FTSP can't work. How about your result? >> Could you print out the log file including the msg->localTime, >> msg->globalTime, timeError, etc for comparasion? >> Thank you very much! >> >> Best regards, >> Han Bin >> >> >> >
_______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
