[Click] schedule tasks [ns-3 + click] + Patch

Eddie Kohler ekohler at gmail.com
Thu Nov 10 08:21:47 EST 2011


Also, thanks for the patch! It's applied.

E


On Thu, Nov 10, 2011 at 8:19 AM, Eddie Kohler <ekohler at gmail.com> wrote:
> Hi Sascha,
>
> What was the typo?? Do I need to check something in?
>
> I imagine that the simulation has sped up because before, Click could
> schedule 2 timers on the ns core, each time it ran -- once for the
> next timer, and once the "+ 1 us" timer for tasks.  So ns probably
> slowed down from handling timers.
>
> Eddie
>
>
> On Thu, Nov 10, 2011 at 7:42 AM, Sascha Alexander Jopen
> <jopen at informatik.uni-bonn.de> wrote:
>> Hey,
>>
>> after fixing a small typo, the modifications provided by you work well.
>> Both testcases run fine. By the way, your solution seems to run much
>> faster in the simulator, but why? Shouldn't active() evaluate to true,
>> whenever a task is in the queue, effectivly driving the simulation in
>> 1us steps with elements like RatedSource or the like? This would lead to
>> roughly the same performance as with Björns or my modifications.
>>
>> Anyway, thank you for this solution.
>>
>> 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
>>> <jopen at informatik.uni-bonn.de> 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
>>>>>> click at amsterdam.lcs.mit.edu
>>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> click mailing list
>>>>> click at amsterdam.lcs.mit.edu
>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>
>>>>
>>>> _______________________________________________
>>>> click mailing list
>>>> click at amsterdam.lcs.mit.edu
>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>
>>>>
>>
>>
>



More information about the click mailing list