Performance of LTE-simulator

[Fernando Salvago]

Hi everybody,

I would like to ask about the performance of the simulator. But in this case I'm not interested in the performance of the network inside the simulator. I would like to know the performance of the simulator when running simulations.

For example, we are running simulations on a server with an Intel Xeon CPU ES-2650 V2 2.60GHz x 8 and a RAM memory of 12GB which I consider very powerful compared to normal laptops, but even in that server a simulation of 5 UEs ( each one with mobility model, data trafffic model) and 1 eNodeB, depending on the simulation time, if the simulation time is 100 seconds, the running time of all the process can get up to 3 hours or more.

So for me it's very unlikely to run a simulation with such a high number of connections as in this question of the forum: https://groups.google.com/forum/#!searchin/ns-3-users/performance%7Csort:relevance/ns-3-users/VqNZogTqBMQ/yaXu-mwNBQAJ

Can anyone give me some information related to this issue?

Thanks very much,

Best regards.

[Konstantinos]

Hi Fernando,

I would suggest to study the profiling documentation (https://www.nsnam.org/docs/models/html/lte-profiling.html) for LTE module.

It will give you some indication of the time needed to run a simulation.

In order to reduce the time required to run the simulation, there are a few tricks.

- configure/build in optimisation mode (https://www.nsnam.org/docs/tutorial/html/getting-started.html#build-profiles)

- static libraries may increase the runtime

- reduce i/o operations to minimum

Generally, LTE module is slow compared to e.g. p2p, due to the details and complexity that are implemented. 
Also, LTE module is very hard/complex to run in parallel mode in order to take advantage of all the cores on your system (https://groups.google.com/d/msg/ns-3-users/0ObxHnrIT8M/uk-UqVxqP7QJ).

So now it simply uses one code/thread for your Xeon CPU. 

You could however run multiple independent (different configurations and/or rng-run) simulations simultaneously on different cores.

Regards,

K

[Fernando Salvago]

Thanks Konstantinos for answer!

It is exactly what I was looking for. I will have a look to all this documentation. There are some modules of NS3 I haven't used yet and I would like to have time to do so. And I didn't even know about profiling. I will look at profiling.

Thanks again.

Best regards.

[Madan Pande]

Hi,

            What Dr. K  says is very much the way to go.

Now, to the point of simulating long running simulations to exemplify what Dr. K said,  open up four terminals for a quad core CPU or more if you have more cores, but do set a threshold with psensor to watch the heating up, a lot depends upon the system config, and run the same script on all of them. Configure the system so that the outputs can be merged if so required, particularly, if you wish to draw graphs of the results...Donot do more than essential logging (if required at all), and may I add that NS-3 is one of the few simulators that does a lot without taking much time at all...  The trick is in designing your script and the scenario it is simulating, this need some thoughtful optimization surely...

Regards,

madan

P.S> I find your observation on your server being better than any latop shows that you missed out on Mobile Workstations that are hi-perf latops and used by professionals in the Industry...

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at https://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

[Natale Patriciello]

On 08/09/16 at 06:51am, Madan Pande wrote:
> Now, to the point of simulating long running simulations to exemplify
> what Dr. K said, open up four terminals for a quad core CPU or more
> if you have more cores, but do set a threshold with psensor to watch
> the heating up, a lot depends upon the system config, and run the same
> script on all of them. Configure the system so that the outputs can be
> merged if so required, particularly, if you wish to draw graphs of the
> results...

This is very windows-based way to do it.
There is the 'GNU parallel' program that can help in this matter (but
before using it you should learn how to avoid waf to launch your
programs). For the outputs, just write .txt file with different names,
and then collect them into a database or another kind of data manager,
and do the plot with external program (like gnuplot).

So, I agree with you: if you have many simulations, you can easily run
them in parallel, since one instance of ns-3 uses at maximum one core.

Nat

[Madan Pande]

Hi Nat Sir,

               With all due respects, it is a very much Unix way to do so... Windows grew out of OpenVMS and Unix incidently

2. IMHO, since a discrete event simulation puts events in a queue, and fetches them as time advances on the the Simulator, it is not always possible to do parallel executions with threads using only one CPU (I am not referring to kernel threads, aka HP-UX or OpenVMS or Digital Unix).. One could rewrite the script in a way that would keep parallelly executable code out side the main thread and create as many required U-space threads to run them and then call a join at some stage, also collecting the outputs in between if required. It is possible to do so in simulators written in C, C++, Object C++ and Quintus Prolog... However, this is not the case here...

3. I had only pointed to a way to do simultaneous runs with a multi-core CPU... in Unix. I have used it extensively with both NS-3 and LTE-Sim...

With Warm Regards,

madan

[Natale Patriciello]

On 09/09/16 at 07:19am, Madan Pande wrote:
> Hi Nat Sir,
>
> With all due respects, it is a very much Unix way to do
> so... Windows grew out of OpenVMS and Unix incidently

windows-based in the sense of many window opened :)

Nat