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
diff --git a/src/click/model/ipv4-click-routing.cc b/src/click/model/ipv4-click-routing.cc
index 170228e..88efefb 100644
--- a/src/click/model/ipv4-click-routing.cc
+++ b/src/click/model/ipv4-click-routing.cc
@@ -310,7 +310,23 @@ Ipv4ClickRouting::HandleScheduleFromClick (const struct timespec *when)
Time simtime = Time::FromInteger(when->tv_sec, Time::S) + Time::FromInteger(when->tv_nsec, Time::NS);
Time simdelay = simtime - Simulator::Now();
- Simulator::Schedule (simdelay, &Ipv4ClickRouting::RunClickEvent, this);
+ NS_LOG_DEBUG ("HandleScheduleFromClick at " << when->tv_sec << "s " << when->tv_nsec << "us simnow=" << Simulator::Now () << " simdelay=" << simdelay);
+
+ if(m_nextClickScheduleEvent.IsExpired()){
+ m_nextClickScheduleEvent = Simulator::Schedule (simdelay, &Ipv4ClickRouting::RunClickEvent, this);
+ }
+ else {
+ if(simdelay < Simulator::GetDelayLeft(m_nextClickScheduleEvent)){
+ NS_LOG_DEBUG("got earlier schedule than existing one, replacing it (old delay " << Simulator::GetDelayLeft(m_nextClickScheduleEvent) << ")");
+ m_nextClickScheduleEvent.Cancel();
+ m_nextClickScheduleEvent = Simulator::Schedule (simdelay, &Ipv4ClickRouting::RunClickEvent, this);
+ }
+ else {
+ NS_LOG_DEBUG("got later schedule than existing one, dropping new and keeping existing (delay " << Simulator::GetDelayLeft(m_nextClickScheduleEvent) << ")");
+ }
+ }
}
void
diff --git a/src/click/model/ipv4-click-routing.h b/src/click/model/ipv4-click-routing.h
index bd818f9..fbb8289 100644
--- a/src/click/model/ipv4-click-routing.h
+++ b/src/click/model/ipv4-click-routing.h
@@ -26,6 +26,7 @@
#include "ns3/ipv4.h"
#include "ns3/ipv4-routing-protocol.h"
#include "ns3/test.h"
+#include "ns3/event-id.h"
#include <sys/time.h>
#include <sys/types.h>
@@ -255,6 +256,8 @@ private:
bool m_nonDefaultName;
Ptr<Ipv4> m_ipv4;
+
+ EventId m_nextClickScheduleEvent;
#endif /* NS3_CLICK */
};
--
1.7.5.4
_______________________________________________
click mailing list
click@amsterdam.lcs.mit.edu
https://amsterdam.lcs.mit.edu/mailman/listinfo/click
