[ndnSIM] [EXT] Scalability of ndnSIM

Junxiao Shi shijunxiao at email.arizona.edu
Mon Jun 29 08:32:28 PDT 2020


Hi Stéfani

It is normal for a simulation to take much longer wall clock time than
simulated time. ns-3 needs to simulate many nodes in one CPU core, so it
naturally takes a long time.
While ns-3 supports using multiple CPU cores via MPI, it’s limited to point
to point links.

I’d advice against setting a negative nice value. It’ll lead to unstable
system overall. You can instead use CPU isolation (cpuset), if your system
has other usages. Also, disable HyperThreading will improve single core
performance.

You eventually will need to simulate the same scenario with many different
parameters. Look at most publications involving ndnSIM, you’ll notice the
evaluation has plots whose X axis is some kind of parameter such as CS
capacity or link delay. This is your opportunity to speed up the
simulations.

https://yoursunny.com/t/2016/parallelize/
I have this script that allows you to run as many simulations as you have
CPU cores. Suppose your X axis has 16 parameters, you can complete all the
stimulations in 10 hours on a 16-core machine, instead of 160 hours.

Yours, Junxiao

On Mon, Jun 29, 2020 at 10:18 Stéfani Pires via ndnSIM <
ndnsim at lists.cs.ucla.edu> wrote:

> *External Email*
> Hello everyone,
>
> I’m having some performance issues in a project using ndnSIM, and I am
> investigating and having difficulty to understand the scalability of the
> simulator, in particular of the application *ConsumerZipfMandelbrot*.
>
> I’m running pure ndnSIM2.8 in a dedicated machine with the optimized mode
> (./waf configure -d optimized). I also explicitly configured the priority
> of the process with the linux ‘nice’ command, like this: nohup nice -20
> ../waf —run ’simple_test —simTime=100’ &.
>
> I'm showing the results of a simple scenario, the one provided at the
> website (ndn-simple.cpp, with 1 router, 1 producer), in which I modified
> the type and number of consumers, CS size, and the simulation time
> (simTime). Sending the base file as an attachment.
>
> In the following tables, I present the execution time (in hours) of some
> of the variations I tested. Those are not deterministic times, and they
> naturally vary when executed again, but I believe they can illustrate my
> question in this email.
> > Is that the expected behavior in terms of increase of the execution
> time, when the number of *consumersZipf* increases?
> > Is my scenario configured correctly?
>
> In my final project, I will need to configure even higher simulation
> times, with more nodes/ConsumersZipf, but it is being prohibitive. I intend
> to configure wireless links, instead of point-to-point.
>
> _______simTime = 50.000 s ______
> n  |  ConsumerCbr | ConsumerZipf
> 1  |      2.365 h         |      2.218 h
> 2  |      1.832 h         |      4.618 h
> 3  |      1.849 h         |      7.431 h
> 4  |      1.790 h         |      10.391 h
>
> _______simTime = 100.000 s ______
> n  |  ConsumerCbr | ConsumerZipf
> 1  |      9.960 h       |      9.751 h
> 2  |       7.448 h       |      20.007 h
>
> Can anyone help me to understand this behavior? I really appreciate your
> considerations.
>
> Best regards ,
> Stéfani Pires
>
> _______________________________________________
> ndnSIM mailing list
> ndnSIM at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20200629/27e3ac1a/attachment-0001.html>


More information about the ndnSIM mailing list