Re: schedule tasks [ns-3 + click]

Hi,

my tests went well so far, and i also noticed from the tests that the 
artificial 1us steps i did not like were gone. If that's intended: 
double thumbs up!

Regards, Björn

On 21.12.2011 11:50, Sascha Alexander Jopen wrote:
> Hey Eddie,
>
> i didnt' test you changes yet, but after looking into the code i think
> you accidently removed the newly introduced artificial time increase in
> lib/routerthread.cc line 683. I think this should read
>
> struct timeval nexttime = (Timestamp::now() +
> Timestamp::make_usec(1)).timeval_ceil();
>
> Regards,
> Sascha
>
> Am 20.12.2011 17:31, schrieb Eddie Kohler:
>> Hi Sascha,
>>
>> I applied a different version of your patch, using a new function
>> (Timestamp::timeval_ceil()) written for the purpose. This also
>> slightly changed the active() case in ns3 scheduling. Take a look;
>> does it work for you?
>>
>> Best,
>> Eddie
>>
>>
>> On Fri, Dec 16, 2011 at 5:40 PM, Sascha Alexander Jopen
>> <[email protected]>  wrote:
>>> Hey Eddie,
>>>
>>> i think my patch is still necessary.
>>> The one integrated into ns3 is about rounding errors between double
>>> and integer time representations, which led to similar endless loops
>>> but on ns3 side.
>>>
>>> Regards,
>>> Sascha
>>>
>>> Am 16.12.2011 15:20, schrieb Eddie Kohler:
>>>> Hi Björn, Sascha,
>>>>
>>>> So, I'm a bit behind. Should I apply Sascha's patch, or some other
>>>> version?
>>>>
>>>> Best, Eddie
>>>>
>>>>
>>>> On 12/04/2011 10:25 AM, Björn Lichtblau wrote:
>>>>> Hi, this flaw was already fixed on ns3 side (in ns3-dev):
>>>>> http://code.nsnam.org/ns-3-dev/rev/0d04b625ea54
>>>>>
>>>>> Regarding Eddies change, it works but i had no time yet to test
>>>>> it extensively. While it works i think it's a little work around
>>>>> to let the simulator do artificial 1 us steps... however it
>>>>> should not hurt in most cases and doing it cleaner my be hard..
>>>>> i'll comment more detailed soon.
>>>>>
>>>>> Regards, Björn
>>>>>
>>>>> On 03.12.2011 23:42, Sascha Alexander Jopen wrote:
>>>>>> Hey,
>>>>>>
>>>>>> after running some real simulations i found that scheduling
>>>>>> timers may lead to infinite loops with nsclicks scheduling. On
>>>>>> 64bit systems the nanosecond precision of a timestamp is mapped
>>>>>> to a truncated microsecond precision timeval. The next ns event
>>>>>> is scheduled at this microsecond timeval, but clicks
>>>>>> run_timers() method doesn't run the timer, because its expiry
>>>>>> is not reached. nsclick is then again scheduled for this timer,
>>>>>> again some nanoseconds to early.
>>>>>>
>>>>>> The attached patch fixes this problem by scheduling nsclick to
>>>>>> the next microsecond after the timer expires.
>>>>>>
>>>>>> Regards, Sascha
>>>>>>
>>>>>> On 11/09/11 18:56, Eddie Kohler wrote:
>>>>>>> Sascha, Björn,
>>>>>>>
>>>>>>> Thanks for your patience with this problem.  I took a look at
>>>>>>> the patch, but decided to do it a different way that is less
>>>>>>> intrusive and hopefully addresses all the cases.  The checkin
>>>>>>> is here:
>>>>>>>
>>>>>>> https://github.com/kohler/click/commit/e3c9f295ea1d5c5700e26f19afce873b0ce755f5
>>>>>>>
>>>>>>>
>>>>>>>
>>> Please let me know if this does not work (I have not tested it).
>>>>>>> Best, Eddie
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Nov 4, 2011 at 3:05 PM, Sascha Alexander Jopen
>>>>>>> <[email protected]>    wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> after rereading the stated problems, i found that my patch
>>>>>>>> did not catch the case when a timer schedules a task. The
>>>>>>>> attached patch should fix this. Both test scenarios from
>>>>>>>> Björn seem to run as expected with this patch.
>>>>>>>>
>>>>>>>> However, i'm still not sure, how much time should pass
>>>>>>>> between two driver runs.
>>>>>>>>
>>>>>>>> Regards, Sascha
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/04/11 17:28, Sascha Alexander Jopen wrote:
>>>>>>>>> Hey,
>>>>>>>>>
>>>>>>>>> i use a slightly different fix. After running the tasks,
>>>>>>>>> i check if there is still at least one task scheduled. If
>>>>>>>>> this is the case, i reschedule the router thread for
>>>>>>>>> execution in ns-3 again with the smallest possible time
>>>>>>>>> offset, which is one microsecond. This way it doesn't
>>>>>>>>> matter if there are other timers to be executed or not.
>>>>>>>>> For elements which do polling using tasks all the time,
>>>>>>>>> this means that simulation time advances only one
>>>>>>>>> microsecond per iteration which could lead to really long
>>>>>>>>> running simulations. Using such elements is possible this
>>>>>>>>> way, however.
>>>>>>>>>
>>>>>>>>> Regards, Sascha
>>>>>>>>>
>>>>>>>>> On 11/04/11 12:15, Björn Lichtblau wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> i think you are experiencing what i described as
>>>>>>>>>> problem A in
>>>>>>>>>> http://pdos.csail.mit.edu/pipermail/click/2011-October/010357.html
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>> Tasks getting scheduled by a fired timer are not run immediatly, because
>>>>>>>>>> run_timers() is behind run_tasks() and the
>>>>>>>>>> routerthread-driver() loop is only run once at each
>>>>>>>>>> call from the simulation. The fix i described there
>>>>>>>>>> however was not correct, currently i'm working with
>>>>>>>>>> this (but maybe incorrect too):
>>>>>>>>>>
>>>>>>>>>> diff --git a/lib/routerthread.cc b/lib/routerthread.cc
>>>>>>>>>> index d118a91..7232b79 100644 ---
>>>>>>>>>> a/lib/routerthread.cc +++ b/lib/routerthread.cc @@
>>>>>>>>>> -640,14 +640,7 @@ RouterThread::driver() _oticks =
>>>>>>>>>> ticks; #endif timer_set().run_timers(this, _master);
>>>>>>>>>> -#if CLICK_NS -           // If there's another timer,
>>>>>>>>>> tell the simulator to make us -           // run when
>>>>>>>>>> it's due to go off. -           if (Timestamp
>>>>>>>>>> next_expiry = timer_set().timer_expiry_steady()) { -
>>>>>>>>>> struct timeval nexttime = next_expiry.timeval(); -
>>>>>>>>>> simclick_sim_command(_master->simnode(),
>>>>>>>>>> SIMCLICK_SCHEDULE,&nexttime); -           } -#endif + }
>>>>>>>>>> while (0);
>>>>>>>>>>
>>>>>>>>>> // run operating system @@ -667,7 +660,20 @@
>>>>>>>>>> RouterThread::driver() #if CLICK_NS || BSD_NETISRSCHED
>>>>>>>>>> // Everyone except the NS driver stays in driver()
>>>>>>>>>> until the driver is // stopped. -       break; +
>>>>>>>>>> if(task_begin() == task_end()){ +#if CLICK_NS +
>>>>>>>>>> // If there's another timer, tell the simulator to make
>>>>>>>>>> us +           // run when it's due to go off. +
>>>>>>>>>> if (Timestamp next_expiry =
>>>>>>>>>> timer_set().timer_expiry_steady()) { +
>>>>>>>>>> struct timeval nexttime = next_expiry.timeval(); +
>>>>>>>>>> simclick_sim_command(_master->simnode(),
>>>>>>>>>> SIMCLICK_SCHEDULE,&nexttime); +           } +#endif +
>>>>>>>>>> break; + +       } #endif }
>>>>>>>>>>
>>>>>>>>>> So the driver loop only exits on task_begin() ==
>>>>>>>>>> task_end() (means it will loop again if a timer
>>>>>>>>>> scheduled a task), and we only tell the simulator to
>>>>>>>>>> schedule a timer when the loop is exiting. While this
>>>>>>>>>> is fine for me a colleague working with ns2 still has
>>>>>>>>>> problems with ToSimDevice in some cases which is too
>>>>>>>>>> much to describe now.
>>>>>>>>>>
>>>>>>>>>> Another potential problem i stumbled over in the
>>>>>>>>>> documentation
>>>>>>>>>> (http://www.read.cs.ucla.edu/click/doxygen/classTimer.html)
>>>>>>>>>> is busy waiting: "Particularly at user level, there can
>>>>>>>>>> be a significant delay between a Timer's nominal
>>>>>>>>>> expiration time and the actual time it runs. Elements
>>>>>>>>>> that desire extremely precise timings should combine a
>>>>>>>>>> Timer with a Task. The Timer is set to go off a bit
>>>>>>>>>> before the true expiration time (see
>>>>>>>>>> Timer::adjustment()), after which the Task polls the
>>>>>>>>>> CPU until the actual expiration time arrives."
>>>>>>>>>>
>>>>>>>>>> Elements doing busy waiting are a big headache in the
>>>>>>>>>> sim environment, and no nice idea yet to fix such
>>>>>>>>>> cases, because time will never advance without setting
>>>>>>>>>> a timer...
>>>>>>>>>>
>>>>>>>>>> Regards, Björn
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 11/04/2011 11:29 AM, Giovanni Di Stasi wrote:
>>>>>>>>>>> Hi everyone,
>>>>>>>>>>>
>>>>>>>>>>> I have developed an element which behaves like a
>>>>>>>>>>> Queue. It has a pull output which is connected to a
>>>>>>>>>>> ToSimDevice.
>>>>>>>>>>>
>>>>>>>>>>> Sometimes, when the pull gets called on the element,
>>>>>>>>>>> it returns a NULL and sets a timer which expires
>>>>>>>>>>> after a few milliseconds (e.g. 3). When the timer
>>>>>>>>>>> expires, an empty_notifier is "activated"
>>>>>>>>>>> (empty_not.wake()). I would expect, at this point,
>>>>>>>>>>> the ToSimDevice task to be run, and the pull to be
>>>>>>>>>>> called on my element.
>>>>>>>>>>>
>>>>>>>>>>> Unfortunately this does not happen. The Task schedule
>>>>>>>>>>> function  seems to be called after the notifier is
>>>>>>>>>>> waken up, but the task is not run. Is this normal?
>>>>>>>>>>> The task is sometimes run a few seconds later. So I
>>>>>>>>>>> have two doubts: is it possible to schedule a task to
>>>>>>>>>>> be run right away (maybe be putting it at the top of
>>>>>>>>>>> the Click pending tasks)? If not, which delay should
>>>>>>>>>>> I expect from the moment I schedule the Task and the
>>>>>>>>>>> moment it gets executed?
>>>>>>>>>>>
>>>>>>>>>>> Thanks, Giovanni
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________ click
>>>>>>>>>> mailing list [email protected]
>>>>>>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>>>>>>
>>>>>>>>> _______________________________________________ click
>>>>>>>>> mailing list [email protected]
>>>>>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>>>>> _______________________________________________ click
>>>>>>>> mailing list [email protected]
>>>>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> _______________________________________________ click mailing
>>>>>> list [email protected]
>>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>> _______________________________________________ click mailing
>>>>> list [email protected]
>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>> _______________________________________________ click mailing list
>>>> [email protected]
>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>> _______________________________________________
>>> click mailing list
>>> [email protected]
>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> _______________________________________________
> click mailing list
> [email protected]
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click


_______________________________________________
click mailing list
[email protected]
https://amsterdam.lcs.mit.edu/mailman/listinfo/click