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

[Sascha Alexander Jopen]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: click-ns3-tasks.patch
Type: text/x-patch
Size: 1268 bytes
Desc: not available
Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20111104/7d72fa51/attachment.bin