Hi everyone,
a point of attention: if you put these files in the correct directory
of the NS-2 allinone package and perform ./install again, it is
possible that the ns binairy is not updated in the /usr/local/bin
directory. In this case just perform a make and a sudo make install in
the ns-2 subdir of the allinone package dir, and check if the
/usr/local/bin/ns file is updated.
My results with this patch are quite encouraging: a simulation of 300
node that previously took 38 hours to complete now only takes 4
minutes! If other members of this list could confirm similar results, i
will update the Nsclick patches to include the changes.
Regards,
Wim
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
--
Wim Vandenberghe
Department of Information Technology
Internet Based Communication Networks and Services (IBCN)
Ghent University - IBBT
Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
T: +32 9 33 14946 ; T Secr: +32 9 33 14900
F: +32 9 33 14899
E: [email protected]
W : www.ibcn.intec.UGent.be
|
_______________________________________________
click mailing list
[email protected]
https://amsterdam.lcs.mit.edu/mailman/listinfo/click
