Re: NSClick - performance upgrade for NS-2

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
> [email protected]
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click