Hi Björn, That's *exactly* what I was thinking!
But I think we could do that without an NS patch, by changing Click (lib/routerthread.cc), so that it doesn't call "simclick_sim_send(...SCHEDULE...)" unless it knows there is no timer scheduled. I slightly prefer to change the Click side, but only slightly. The division of functionality between Click and the NS driver is pretty ad hoc. E On 1/19/12 2:45 PM, Björn Lichtblau wrote: > Hi, > > I saw the same behaviour recently with ns3. I think you can't prevent > it? For example: > > 0s: An element schedules itself to run in 3s, which click tells the sim. > 1s: sim has a packet for click which results in another element > scheduling in 1s. > > Now click must tell the sim to get scheduled at 2s, although 3s is still > pending. And when click is called at 2s it schedules the second time for > 3s (events may pile up if neither click nor sim cares). > > But I think handling by the sim is much easier, the interface is fine as > is (just needs doc). > The sim needs to keep the next schedule only, later ones can be dropped > because click always schedules the next event (if there is one) at the > end of each routerthread/driver invocation. If an earlier schedule comes > in you need to replace that, no map for bookkeeping needed on neither side. > > Attached is a patch which i intended to submit to ns3 soon and worked > well for me, am i missing something? > > Best regards, Björn > > > On 19.01.2012 18:10, Eddie Kohler wrote: >> Hi Wim, >> >> I'll take a version of this if no one else mentions a problem. But >> perhaps it would be good to separate out the easy from the hard >> problems. It would be easy to, entirely on the Click side, prevent a >> single node from scheduling itself multiple times in the future. That >> would apply to ns2 and ns3 I think(i am really not an expert on click's >> ns driver). Should we just do that first& see how much it helps? >> >> E >> >> >> On 1/18/12 10:25 AM, Wim Vandenberghe wrote: >>> Hi everyone, >>> >>> because i am having problems with Nsclick simulations that take forever >>> to complete, i have been looking at possible causes. I've identified a >>> flaw in the scheduling. Everytime the driver() function of >>> routerthread.cc is executed (which is caused by timer expiration or >>> packet reception), it schedules itself again in NS-2 if it has a timer >>> that is scheduled to go off in the future. As a result, many duplicate >>> schedules are introduced for the same node for exactly the same point in >>> simulation time. This introduces great overhead when this point in >>> simulation time is reached and all these duplicate events have to be >>> executed. >>> >>> I've found a very old post on the mailing list by Michael Neufeld >>> (http://pdos.csail.mit.edu/pipermail/click/2004-May/002706.html) which >>> presented a hack to overcome this problem. Basically he keeps a global >>> map of points in time for which a ClickEvent is scheduled. If a node >>> schedules a new event, it will be added to the unique already existing >>> event for that given moment in time. During this addition, a check is >>> performed to make sure that you schedule a node only once for a single >>> point in time. >>> >>> This code however was never introduced into mainstream click. I have >>> implemented a new version which should be compatible with recent Click >>> releases. The files can be found in attachment. They have to be put in >>> the classifier directory of the NS-2 sources. >>> >>> Perhaps it would be interesting if some people using NSClick in NS-2 >>> could try these files, and see if they also observe an improvement in >>> performance, and if it does not introduce any bias in the simulation >>> results? Also, i have tested it with Click 1.7 (upgrading is still on my >>> to-do list) and NS2.34, experience with current git sources would also >>> be interesting. >>> >>> Regards, >>> >>> Wim >>> >>> >>> PS: I also noticed that using a QuickNoteQueue instead of a standard >>> Queue improves performance since the run_task of the tosimdevice will >>> halt quicker when there are >>> no more packets left in the queue >>> >>> >>> >>> _______________________________________________ >>> 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
