[Ns-developers] Internal Time Keeping Question

[Mathieu Lacage]

On Tue, 2008-07-22 at 18:43 +0200, Hagen Paul Pfeifer wrote:
> On Tue, 22 Jul 2008 08:50:15 -0700, Tom Henderson <tomh at tomh.org> wrote:
> 
> 
> 
> >> @George: should I adopt the concept of Ghost in this scenario? Build a
> 
> >> lightweight infrastructure based on federate information? This will lead
> 
> > to
> 
> >> huge infrastructure changes in ns-3, as far as I can estimate.
> 
> >>
> 
> >>
> 
> > Hagen,
> 
> > Your last sentence above concerns me.  Are you on a path that is
> 
> > compatible with our current architecture?
> 
> 
> 
> Until now there is really no code impact, except ~10 lines of code. So far
> 
> so good!
> 
> 
> 
> The challenge now is that ns-3 was not designed to run in a strictly
> 
> parallelized mode. The question to George aimed on an optimization
> 
> technique. The challenge what I realized is that if I parallelize the whole
> 
> the scenario in a dumb manner every physical instance must setup the whole
> 
> scenario! For example: if there are 40 simulated nodes and we are working
> 
> on a quad-core processor we must set up all 40 nodes on all cores which
> 
> will result in 160 allocated nodes! My question to George concerns about a
> 
> optimization technique.

Are you suggesting that you plan to run the whole simulation in each
node if you do not use ghost nodes ? 

i.e., let's say I have 2 federates, A and B and two nodes, C and D.
Let's say that C is assigned to A and D assigned to B. Let's say that A
has a traffic generating application. What does the user script look
like to do this ? If it looks like a normal script, how do you plan to
selectively enable the traffic generation on only federate C ?

> Another challenge is that there is no uniform API to inject Packets into
> 
> the simulator. The whole simulator is based on a object method call
> 
> principle. For disadvantage is that this requires the reference to this
> 
> object - but how could a central place (where the Packet is received)
> 
> should know the object reference? The idea is to store register devices in
> 
> a collector class (whatever) and fetch the reference based on the device
> 
> ID. The ID of the device must be unique across the simulated plattform.

The key is that the piece of code which sends the MPI message must have
a unique id to identify the destination of the MPI message. In your
context, you must have a unique ID per PointToPointNetDevice to allow
the receiving mpi code to forward the received message to the correct
PointToPointNetDevice. A simple global unique ID would be the nodeid
+deviceid pair.

Mathieu