[Ns-developers] Status Parallelization

[Hagen Paul Pfeifer]

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