Marcin, I'm sorry you had so much trouble with FTSP; this is exactly the kind of reason why we distribute a specific version of msp430/avr compilers. When we do discover a bug like the one you describe with the standard compiler,g generally the answer is to restructure/rewrite the code so it doesn't tickle the compiler bug.
Phil On Sep 30, 2012, at 4:03 PM, Marcin Szczodrak wrote: > 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 <[email protected]> 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 <[email protected]> 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 > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
