Hi Marcin, I am also interested to work with this algorithm, and for that, form the last one week, I am trying to run it on some publically available testbeds, but the worst part is that I receive no logs, I have tried to test the code locally, as you are doing, running it on your predefined topology it works (just hte logging stuff, I haven't checked the syn state of the nodes), but when I try to run the same code on testbeds like Indria or Harvard motelab, nothing is logged. So, at the moment, I am stucked in how to just make it run, whenever I will get through it, I will get back to you.
But in the mean time, if you have accounts on the aforementioned testbeds, could you also run your code over there, lets just say on 3 to 4 nodes only, just for the sake of clearity. Regards, Wasif! On Mon, Sep 24, 2012 at 12:50 AM, Marcin Szczodrak <[email protected]> wrote: > Hi, > > I have noticed that FTSP does not pass the test from > apps/tests/TestFtsp/Ftsp . I've configured couple of tests as > explained in the Ftsp apps' README, and once I deployed all the motes > I could not see them being synchronized. In my test scenario I've used > 4 tesloB motes running in 3 different configurations on TinyOS 2.1.2, > latest TinyOS 2.x with the last update from Sep 21, and TinyOS 2.x > with cc2420x. All motes were placed withing a distance of <1 feet from > each other. For each of the tests I called reports that can be found > under the following links: > http://www.cs.columbia.edu/~msz/ftsp/ftsp_test_tos_2.1.2.report > http://www.cs.columbia.edu/~msz/ftsp/ftsp_test_tos_2.x.report > http://www.cs.columbia.edu/~msz/ftsp/ftsp_test_tos_2.x_cc2420x.report > > First, I would like to ask if anyone else observes the same problem > with that test? > > For a while I was thinking that there is a bug somewhere is my code, > but after taking clean TinyOS 2.x and clean TinyOS 2.1.2 I was still > getting the problem, I started to investigate the FTSP implementation. > I tried the tricks/hacks already posted on the list, including the one > with always setting global time to local time in case of the root node > ( > https://www.millennium.berkeley.edu/pipermail/tinyos-help/2012-July/055203.html > ), > but none of them worked out. I added few printf lines into the > TestFtspP to see what's going on inside. I collected logs that can be > found under the following links: > http://www.cs.columbia.edu/~msz/ftsp/mote_1.txt > http://www.cs.columbia.edu/~msz/ftsp/mote_2.txt > http://www.cs.columbia.edu/~msz/ftsp/mote_3.txt > http://www.cs.columbia.edu/~msz/ftsp/mote_4.txt > > Based on the logs, one can observe that the timeError (computed at > addNewEntry() ) is way too high than its limit ( ENTRY_SEND_LIMIT = > 500 by default). > > I also tried to run the Ftsp app test with 4 telosb motes running FTSP > test app and 2 Z1s running RadioToCount and BaseStation. > http://www.cs.columbia.edu/~msz/ftsp/telosb-1-2-3-4.report > http://www.cs.columbia.edu/~msz/ftsp/telosb-4-3-2-1.report > In the first test, Ftsp nodes (1,2,3,4) are started in increasing > TOS_NODE_ID order, so right-away mote 1 is the root. In the other > experiment I started the motes in mote's ID decreasing order, so the > time-root was changing. Both tests have failed, and the second one > also gave strange globalTime estimate 4294483947 which I have noticed > in few other experiments that I'm not reporting here (probably there > is type variable issue?). > > Second, I wounder if someone might have ideas where should I look > into. At this moment I have a feeling that somewhere time-stamping is > done incorrectly but I will need more tests to check that. > > Thanks, > Marcin > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > -- Wasif Masood
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
