Paul, Thank you very much.I got it.
sincerely, On Wed, Nov 18, 2009 at 1:50 AM, Paul Johnson <[email protected]> wrote: > Mojtaba, > > As I said before, there is nothing wrong, you are interpreting the time > information incorrectly. > > When you print sim_time() it is in 10^-9 of a second(i believe). This > means that there are 10^9 "ticks" per second. The python function > bootAtTime uses these ticks to set the boot time of the node. Your timer > counts differently, it has 1024(maybe it's 1000 in TOSSIM) ticks per > second(not how often it fires, but how often it changes), this means that > each tick of your timer is equal to 10^9/1024 or 976,562.5(or 1,000,000 for > TOSSIM) sim ticks. Since your timer ticks 1000 times before firing, you > should see the first tick somewhere around 976,562,500(or 1,000,000,000) > simulation time. You saw an event at *1,175,691,828. *This looks about > right to me. > > -Paul > > > mojtaba raznahan wrote: > > Paul, > > thanks,Yes corrected by %lu. > but why between this to line of code there is a big gap ? > > *dbg("Control","AMControl started Successfully %lu .\n",sim_time()); > if(TOS_NODE_ID == 1 ) { > dbg("Base","This is the base station...ready for sending packets > %lu.\n",sim_time()); > call Timer.startPeriodic(TIMER_DELAY); > } > > *In the output i have this times : > > *DEBUG (0): Booted at time 1024 **--->it's true* > *DEBUG (0): AMControl started Successfully 1124 . **--->it's true* > *DEBUG (1): Booted at time 1320 .**--->it's true* > *DEBUG (1): AMControl started Successfully 1420 .**--->it's true* > *DEBUG (1): This is the base station...ready for sending packets 1420. > --->it's > true* > *DEBUG (2): Booted at time 6000 .**--->it's true* > *DEBUG (2): AMControl started Successfully 6100 .**--->it's true* > *DEBUG (1): Timer fired at 1175691828 ---->What's wrong ? > DEBUG (1): Packet sent at 1175691828 data is :2 > DEBUG (2): The Packet recieved at 1195375551 and the length is : 0000000002 > and data is :7. > DEBUG (0): The Packet recieved at 1195375551 and the length is : 0000000002 > and data is :7. > DEBUG (1): sendDone at 1197054008. > > * > > On Tue, Nov 17, 2009 at 9:43 PM, Paul Johnson <[email protected]> wrote: > >> Mojtaba, >> >> %d in printf is used for signed 16 bit integers, you need to use %lu for >> 32 bit unsigned integers. >> >> -Paul >> >> >> mojtaba raznahan wrote: >> >> You're right, >> >> Paul,sim_time() returns an uint32_t measure.I see this number in the >> program : >> >> *DEBUG (0): Booted at time 1024 >> DEBUG (1): Booted at time 1320 >> DEBUG (2): Booted at time 6000 >> . >> . >> DEBUG (1): Timer fired at 1175691828 >> DEBUG (1): Timer fired at -1943585060 >> DEBUG (1): Timer fired at -767894652 >> DEBUG (1): Timer fired at 407795756 >> .* >> . >> . >> >> What is this negative numbers ? Is it because of overflow ? my boot times >> are : >> >> *t.getNode(0).bootAtTime(1024); >> t.getNode(1).bootAtTime(1320); >> t.getNode(2).bootAtTime(6000);* >> >> and I use this statement to print the time in the code : >> *dbg("Base","Timer fired at %d\n",sim_time());* >> >> And timer period is 1000.But when is use sim_time_string() it returns the >> correct form of time as I said before. >> >> Thanks, >> >> On Tue, Nov 17, 2009 at 8:51 PM, Paul Johnson <[email protected]> wrote: >> >>> Yes, you can do that, but it won't accurately model a real clock because >>> of clock skew. In general, clocks do not run at the exact same rate, their >>> frequency tends to drift. This drift depends on a lot of factors such as >>> temperature, humidity, etc. In TOSSIM there is no support for clock skew. >>> Another drawback of simulation is that it doesn't simulate processing time. >>> This means that you will never have any jitter (the non-deterministic timing >>> differences between receiving a packet and processing it, or preparing a >>> packet, and sending it). >>> >>> These two factors are what makes time synchronization a non-trivial >>> problem. Using TOSSIM you could check your algorithm to see if it sends >>> messages correctly, parses received messages correctly, corrects the random >>> offset between nodes, etc, but you will not be able to see how accurate the >>> synchronization is using pure simulation. >>> >>> -Paul >>> >>> >>> mojtaba raznahan wrote: >>> >>> I think i should solve this problem by specifying random numbers as clock >>> offset between motes,and sim_time() as global time. >>> >>> On Mon, Nov 16, 2009 at 10:31 PM, mojtaba raznahan < >>> [email protected]> wrote: >>> >>>> Paul, >>>> >>>> Thanks again for your clear answers. >>>> >>>> Yes, I think like you.So due to this issue I can't test time >>>> synchronization algorithms in TOSSIM,am I right ?Or maybe there is some >>>> interface for doing this job .. ? >>>> >>>> sincerley, >>>> Mojtaba >>>> >>>> On Mon, Nov 16, 2009 at 9:58 PM, Paul Johnson <[email protected]>wrote: >>>> >>>>> Mojtaba, >>>>> >>>>> Actually, i believe the bootAtTime is in 100's of pico seconds (10^-10) >>>>> seconds. So 1024 * 10^-10 = 0.0000001024, and apparently >>>>> sim_time_string() >>>>> returns time in seconds (up to nano seconds (10^-9)). There are actually >>>>> 1024 milli "ticks" per second, so this is why each timer fired is adding >>>>> not >>>>> quite 1.0 to the time. >>>>> >>>>> As for your other issue, this is actually by design. If a node >>>>> transmits a broadcast packet, all other nodes in the transmission range >>>>> will >>>>> receive it at the same time. The boot times only change when the node >>>>> powers up, but doesn't skew it's clock. In fact, i can't say for 100%, >>>>> but >>>>> I think that sim_time_string() grabs the global simulation time, and there >>>>> is no local clock simulation is TOSSIM. >>>>> >>>>> -Paul >>>>> >>>>> mojtaba raznahan wrote: >>>>> >>>>> Hi Janos, >>>>> thanks for reply. >>>>> >>>>> What's the meaning of this numbers ? I set the bootAtTime event as >>>>> these : >>>>> >>>>> *t.getNode(0).bootAtTime(1024); >>>>> t.getNode(1).bootAtTime(1320); >>>>> t.getNode(2).bootAtTime(6000)*; >>>>> >>>>> And i get the time by *"sim_time_string()*" method and it print the >>>>> boot times as this : 0:0:0.000000102 and 0:0:0.000000132 and >>>>> 0:0:0.000000600 >>>>> . As i can guess 102 means "1024" MilliSec and 132 means "1320" Milil. >>>>> And I set the startPeriodic at 1000 ,some thing is ambiguous.The last >>>>> statement prints the time equal to 0:0:0.000000142 the next statment is >>>>> *Timer.startPeriodic(1000)*,but in the output when i print the time in >>>>> *Timer.fired()* event, it prints the time equal to *0:0:0.976562642*and >>>>> the later >>>>> *0:0:1.953125142* ,* 0:0:2.929687642*, *0:0:3.906250142* what does it >>>>> mean ? >>>>> And also when i send a packet, the 2 other recievers get the packet at >>>>> the same time!!(I've set the bootTimes differently!). >>>>> >>>>> Thanks, >>>>> Mojtaba >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Nov 16, 2009 at 7:34 PM, Janos Sallai < >>>>> [email protected]> wrote: >>>>> >>>>>> In tossim, the node object in python has a bootAtTime method which >>>>>> lets you set when the mote boots. You can use this to make the local >>>>>> clock's offsets different from each other. By the way, TOSSIM does not >>>>>> simulate clock skew. This might limit the validity of the simulation >>>>>> results. >>>>>> >>>>>> Janos >>>>>> >>>>>> On Mon, Nov 16, 2009 at 7:55 AM, mojtaba raznahan >>>>>> <[email protected]> wrote: >>>>>> > Hi all, >>>>>> > >>>>>> > I want to know how can I set the local time of each mote >>>>>> programmatically ? >>>>>> > I want to set different local time for each node then test my >>>>>> > synchronization algorithm on them. >>>>>> > I used the LocalTime interface to get the local time but i can't set >>>>>> > different initial local time for each node.And LocalTime interface >>>>>> has 2 >>>>>> > type "TMilli" and "TMicro" but when i use TMicro then in >>>>>> configuration >>>>>> > section there isn't any component provider for it! .I'm using Tinyos >>>>>> 2.1.0 >>>>>> > and TOSSIM. >>>>>> > >>>>>> > Regards, >>>>>> > -- >>>>>> > Mojtaba Raznahan >>>>>> > BS of Computer engineering >>>>>> > TMU university >>>>>> > www.raznahan.com >>>>>> > >>>>>> > _______________________________________________ >>>>>> > Tinyos-help mailing list >>>>>> > [email protected] >>>>>> > >>>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>>>>> > >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Mojtaba Raznahan >>>>> BS of Computer engineering >>>>> TMU university >>>>> www.raznahan.com >>>>> >>>>> ------------------------------ >>>>> _______________________________________________ >>>>> Tinyos-help mailing >>>>> [email protected]https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>>>> >>>>> >>>> >>>> >>>> -- >>>> Mojtaba Raznahan >>>> BS of Computer engineering >>>> TMU university >>>> www.raznahan.com >>>> >>> >>> >>> >>> -- >>> Mojtaba Raznahan >>> BS of Computer engineering >>> TMU university >>> www.raznahan.com >>> >>> >> >> >> -- >> Mojtaba Raznahan >> BS of Computer engineering >> TMU university >> www.raznahan.com >> >> > > > -- > Mojtaba Raznahan > BS of Computer engineering > TMU university > www.raznahan.com > > -- Mojtaba Raznahan BS of Computer engineering TMU university www.raznahan.com
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
