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 <jo...@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@amsterdam.lcs.mit.edu >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> >> >> >> _______________________________________________ >> click mailing list >> click@amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > > _______________________________________________ > click mailing list > click@amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > _______________________________________________ click mailing list click@amsterdam.lcs.mit.edu https://amsterdam.lcs.mit.edu/mailman/listinfo/click
