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

[Björn Lichtblau]

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
>
>