Simulating wireless ad-hoc networks with many Linux Containers (lxc)

[Byoungheon Shin]

Dear colleagues,

I have a Java-based application-layer routing protocol developed by myself.

I successfully tested it with four Raspberry Pi's with IEEE 802.11n networks.

Now I need to run the same program with minimum code changes and found that Linux Containers (lxc) is a good option.

I copied the tap-bridge wifi example located in "ns-3.26/src/tap-bridge/examples/tap-wifi-virtual-machine.cc" and extended the number of nodes to 10, and also made each node equip two IEEE 802.11 wifi interfaces.

I also setup bridges and tap interfaces to connect linux containers so that one container has two virtual network interfaces for wifi.

And finally I had to conclude that ns-3 core is totally not scalable. After running the simulation, there was no problem if I just ping to someone in the network. But If I start my routing protocol and generate small "hello" packets every second, the ns-3 core consumes 97~110% of CPU. If I ping to the neighbor node 20m away, RTT becomes more than 20 seconds and continuously increases until I quit. So far, I think that it is not because all containers consume a bunch of computing resources but because the ns-3 core cannot run in parallel. Each container consumed less than 3% of the CPU.

I googled about parallel simulation, but all of them just talk about point-to-point links and even they don't consider linux containers.

My goal is to "use the Java-based routing protocol with many lines of codes and classes" and run simulations.

Now I find that "real-time" simulation with containers is almost impossible. But if I am wrong, please inform me with solutions!! I really need them.

Even I don't need such "real-time" simulations. It is truely OK if the clock can be synchronized with the simulation network, but I have no idea how to do that between the ns-3 simulated network and my Java program.

There is DCE for directly running user application codes, but it only accepts C++... Is there any other way to use that?

Any other suggestions are appreciated!

Best Regards,

-- Byoungheon Shin

[Byoungheon Shin]

Here I write additional information about my simulation environment.

I tested the simulation with two different machines and got the same problem above.

[Device 1]

*Host OS: Ubuntu 14.04 (64-bit)

*CPU: Intel i7-3770K

*RAM: 16GB

[Device 2 (virtual machine)]

*Host OS: Ubuntu 16.04 (64-bit)

*CPU: Intel Zeon E5-2620v3 6C 2.4Ghz (4 cores allocated)

*RAM: 4GB

[Common]

*ns-3 version: 3.26

*Java inside the container: openjdk-7-jdk

*Another tools used inside the container: tcpdump (to parse tcpdump output and monitor flow statistics in the Java application)

*Simulation topology: please check the attached file.

*Actions of the Java application

 - Monitor flow status from tcpdump textual output

 - Periodically broadcast hello packets to check topology (every second)

 - Periodically unicast a delay measurement packet to each neighbor (every second)

 - Based on specific application types, discover and update multi-hop routes between a source and a destination (multi-constrained routing protocol)

 - The routing behaviors are basically following AODV rules (route request, route reply, route error).

Best Regards,

2016년 10월 13일 목요일 오후 4시 38분 23초 UTC+9, Byoungheon Shin 님의 말:

[Tommaso Pecorella]

Hi,

I have not a lare experience with LHC simulations, but I'd try a core-and-edge analysis.

You said that if you just do a ping all works, but when you start your routing protocols problems start growing up.

ns-3 performances depends on the amount of events it has to handle. With a wireless scenario this means the number of packets and the number of receivers. If there are collisions things gets even more complex.

In any case, usually you shouldn't experience the kind of effects you noticed, unless there's a heavy congestion somewhere.

My suggestion is to start with only two nodes and to track the messages in the network, perhaps you'll find some unexpected things, like packet generation synchronization (*).

Cheers,

T.

(*) this is a common problem: real hardware have clock imprecisions and the perfect synchronization is "naturally" avoided. Simulations have perfect clocks and if you start two nodes at the same time, they'll be synchronized.