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
