[Ns-developers] GSOC - Parallel Simulations | First ideas

[Mathieu Lacage]

hey,

I have tried to comment below: the following will hopefully be of some
use to you and if there are gross errors below, someone will probably
spot and report them :)

On Tue, 2008-03-25 at 01:20 +0100, Hagen Paul Pfeifer wrote:

> o Proposed Architecture (still first shots, of course ;):
> 
>   Add an additional parallelization abstraction layer (with well defined
>   interfaces). This enables several possibilities, namely to enable/disable
>   the whole parallelization via a compile time switch ("mark" this feature
>   as experimental in the beginning), make then replaceable and enable the
>   possibility to extend the whole subsystem with additional distribution
>   (cluster functionality) without major code subsitution in the ns-3 core.
> 
>   A clean but powerful parallelization layer is the goal to split
>   implementation issues from the core ns3 logic! At least the newly added
>   functionality should _interference_ the common functionality as less as
>   possible to prevent "simulation result anomalies".

I think that designing an abstraction layer like this would be nice but
that your first goal should be to try to get something running. i.e.,
once you have gotten the thing to run with some speedup, you can try to
design an abstraction layer. So, I would put this as a last
nice-to-have-but-far-from-vital step of your project.

> o In the first part an profiling analysis (code coverage test, oprofile,   et cetera,.)
>   to detect CPU hogs to understand where processing power is consumed. Use this
>   information to find approaches to split workload into several pieces.
>   Currently my knowlendge is limited in this sector an may help me where are
>   the major CPU hogs. 
> 
>   - Spot causal dependencies within the model like global variables. Dig into
>     major components (like wireless node dependencies, like radio
>     interference, et cetera,). Categorize these into several groups to spot out
>     the parallelization possibilities.

It is, indeed, a great idea to take a fresh look at the overall problem
and to try to find optimization opportunities anywhere you can. However,
there are a couple of things which I think you should consider: a very
important characteristic of a final working system is that even though
it might not take the most out of the hardware, it should not require
model developers to be aware of parallelization or to have to think
about it. Because, let's be honest: experience shows that model
developers have barely enough time and energy to develop good
non-parallel models so, they never try to build parallel models.

So, if I were you, I would start by reducing the scope of your project
to ignore the investigation of intra-node parallelization opportunities
because the data-dependence analysis of intra-node code will be hard and
trying to disentangle it will most likely have a very big impact on
model design which, as I mentioned above, is a very big minus.

A simple assumption which is then often made is that the only
data-dependency across nodes is packets flowing along channels which
connect nodes (i.e., no global variable is used to exchange data between
nodes). This makes the data-dependency problem much easier to analyze
because it is reduced to know the physical connectivity of nodes through
channels. So, I think that you could start from there, but that is just
me :)

> o
>   3. Study the literature and other applications with similar behavior

I believe that omnet++ has a nice parallel implementation. see the
sim/parsim directory and its documentation:
http://www.omnetpp.org/doc/parsim-api/main.html


> This is GSOC proposal, most likely not that stable (more alpha like ns3) but
> an attempt! ;)

hopefully, ns-3 and your proposal will get out that alpha state soon !

Mathieu