[Ns-developers] Internal Time Keeping Question

[George Riley]

>
> 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?
Yes, I agree with Tom that we definitely should not do something that  
has huge
infrastructure changes in ns-3; we simply can't do that.

In GTNetS, we specify the mapping of nodes to simulators on the Node  
constructor, with an optional
integer arg secifying which simulator is responsible for state  
maintenance for that node.  In your
code Hagen, how do you plan on specifying this mapping?  It has been  
proposed in the past
that a separate text file contain this, which I am against.  We should  
be able to handle everything
with command line arguments such as "numberLPs=8, myLP = 0" (for  
example).

THoughts?
George
>
>
> 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