[Ns-developers] ns-3-dev performance

[Gustavo Carneiro]

On 3/3/07, mathieu lacage <Mathieu.Lacage at sophia.inria.fr> wrote:
>
> On Sat, 2007-03-03 at 13:40 +0000, Gustavo Carneiro wrote:
> > On 3/3/07, mathieu lacage <Mathieu.Lacage at sophia.inria.fr> wrote:
> > >
> > >
> > > But I would be interested in seeing your benchmark code or real
> > > profiling results (I suggest oprofile for the profiling part). Real
> data
> > > is always interesting.
> >
> >
> >   You're right, profiling is always interesting.  In this case,
> profiling
> > shows that 75% of the CPU time is inserting events into the scheduler:
> >
> > CPU: Core 2, speed 1862 MHz (estimated)
> > Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a
> unit
> > mask of 0x00 (Unhalted core cycles) count 100000
> > samples  %        image name               app name
> symbol
> > name
> >
> -------------------------------------------------------------------------------
> > 1291002  74.9078  libsimulator.so          libsimulator.so
> > ns3::SchedulerList::RealInsert(ns3::EventImpl*,
> ns3::Scheduler::EventKey)
> >   1291002  100.000  libsimulator.so          libsimulator.so
> > ns3::SchedulerList::RealInsert(ns3::EventImpl*,
> ns3::Scheduler::EventKey)
> > [self]
> >
> >   Bottom line is that headers serialization are not responsible for most
> of
> > the time.  So nevermind my suggestion.
> >
> >   Wow!   With the knowledge of the above, I inserted a line
> > "Simulator::SetBinaryHeap ();" into the program, and simulation time
> dropped
> > from about 5 minutes (1 second simulated time) to less than one second
> (!).
> > Amazing.
>
> haha. And what about the StdMap scheduler ? Can it beat the Binary
> Heap ?
>
> An interesting experiment would be also to validate that the Binary Heap
> is not buggy: you would need to enable logging and check that the two
> simulations generate the same log output (beware: can be _very_ large
> files)


  There's an easy way to check that a scheduler is not buggy.  We shouldn't
compare it against our "perfect" scheduler; instead I think we should just
observe that it behaves they way it should, which is rather easy.  We only
need to add a couple of assertions:

    1. For every two consecutive events that have been scheduled, ev1 and
ev2,  time(ev2) must be always greater or equal than time(ev1).
    2. If the simulation stops by exhaustion of events, the number of
inserted events must equal the number of scheduled events (except for the
removed events).

  If 1 and 2 hold, we have a good scheduler.  The patch at
http://telecom.inescporto.pt/~gjc/ns3-schedule-validate.diff does that.

  Regards,

-- 
Gustavo J. A. M. Carneiro
"The universe is always one step beyond logic."