[Ns-developers] Internal Time Keeping Question

Tom Henderson tomh at tomh.org
Tue Jul 22 08:50:15 PDT 2008


Hagen Paul Pfeifer wrote:
> OK, the time synchronization is implemented in a similar way to GTNetS.
> 
> Mathieu: one question regards Packet mutliplexing at Channel level. If you
> consider e.g. the point to point channel. Simulator::Schedule schedules the
> Packet "p" for time "txTime + m_delay", at class "m_link[wire].m_dst" and
> method "&PointToPointNetDevice::Receive". The question that arise is that the
> peer federate (the other psysical ns-3 instance) does not share the memory.
> 
> Currently:
> Simulator::Schedule (txTime + m_delay, &PointToPointNetDevice::Receive, m_link[wire].m_dst, p);
> 
> Better for me would something like:
> Simulator::Schedule (txTime + m_delay, &PointToPointNetDevice::Receive, m_link[wire].m_dst.getID(), p);
> 
> Where m_link[wire].m_dst.getID() would be unique across the whole scenario.
> 
> This mean "m_link[wire].m_dst" (of type Ptr<PointToPointNetDevice>) does not
> exist on the other instance. There are several workarounds but neither is
> optimal: the one will consume memory (cause every instance will allocate and
> set-up infrastructure for the whole simulated topology, furthermore the
> multiplexing logic must decide based on an unique ID what is the correct
> destination device (maybe a hashmap of all devices with a unique device ID
> might be sufficient).
> 
> @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?

I reviewed your example code also (simple-point-to-point-udp-discard). 
On the wiki, you state that there is nothing to do from the API level 
except call Simulator::EnableParallelSimulation().  However, I expected 
to see (and didn't see) some kind of mapping of nodes to physical 
machines.  Is there really no script-level impact of running MPI-based 
simulations?  I do not understand how this could be.

I think it would help to bump up a level and clarify exactly what is the 
end functionality goal of the effort, what are the requirements on the 
ns-3 core for your effort to succeed, and what will be the API impact on 
users.  For instance, you state in your project description that your 
main goal is CPU local parallelization but it seems that your emphasis 
is on MPI recently.

After that, we should identify the paths to mergeable code within the 
project timeframe.

Thanks,
Tom


More information about the Ns-developers mailing list