[Ns-developers] Status Parallelization

[George Riley]

Hagen,
We should discuss.  Unfortunately, I am in a all-morning (and into the  
afternoon)
meeting, so am not sure when I will be free.  What is the latest you  
can get on IRC?
George
--------------------------------------------------
George Riley
Associate Professor
Georgia Tech
Electrical and Computer Engineering
riley at ece.gatech.edu
404-894-4767
Klaus Advanced Computing Building
Room 3360
266 Ferst Drive
Atlanta, Georgia 30332-0765

ECE4110 Web page:
http://users.ece.gatech.edu/~riley/ece4110/

ECE4112 Web page:
http://users.ece.gatech.edu/~riley/ece4112/







On Jun 10, 2008, at 9:19 AM, Hagen Paul Pfeifer wrote:

>
> Hello NS-3 Developers,
>
> since a IRC discussion with Mathieu I temporary dropped the
> approach to start to parallelize the Wifi Channel and switched
> to a more simple Point-to-Point channel. The synchronization is done  
> via
> MPI. And Packet serialization via standard PeekData and Buffer
> class respective. So far this simple scenario works as excepted and  
> via
>
> mpirun --np 2 --mca btl \^udapl,openib
> build/debug/examples/point-to-point-udp-discard
>
> the Packet is transmitted and received.
>
> On the other hand the created scenario synchronization is only half- 
> duplex
> and
> 99% of the implementation is created to work without mass  
> complication.
>
> The main challenge is that ns-3 isn't designed to work in a  
> simultaneously
> manner. Every
> time I introduced a workaround another problem popped up. This  
> starts at
> concurrent IO
> operations, introduced additional looking/barriers to keep in time  
> and end
> with no
> common recv/send interfaces like they did in glomosim (as an  
> example). So
> there is a
> lot of additional work to see an functional parallelized simulator  
> with
> involved major
> code impact in the overall architecture (Mathieu sorry for that - the
> impact will not be
> minimal because synchronization requires a) a lot of infrastructure  
> and b)
> interplay with several components.
>
> So my idea: still focus on a minimal implementation with no or minor  
> focus
> on performance
> BUT first introduce some basic parallelization infrastructure. These
> includes:
>
> a) a proper working Federate system, that handles m nodes (point to  
> point
> as well as
>   CSMA channels) and n different "execution engines" (e.g. Cores).  
> This is
> necessary
>   to get rid of the current "static hacks".
> b) introduce a additional abstraction layer to distribute Packets in a
> central place.
>   They can be no-ops if no distribution is desired. Currently I  
> graped the
> Packet at
>   Channel level, barrier and inject into the Device (where the receive
> routine is
>   located for point to point devices). The additional layer is also
> Mathieu compatible
>   because there are fewer places where parallelized code is added.
> c) Discuss and implement a really simple time synchronization  
> mechanism and
> extend
>   the run queue to work in a distributed manner.
> d) Think about the current IO subsystems (trace files, pcap files).  
> E.g.
> the DaSSF
>   network simulator (dartmouth.edu) shift the processing to the end.  
> Where
> all
>   concurrent "threads" already joined.
>
> George, what are your suggestions (also experiences with GTNetS)?
>
> Hagen
>
>