HOWTO run simultaneous Cooja simulations

If you are running Cooja on the BSOE “dance” compute servers, then you may have discovered that sometimes it’s not possible to start a second command-line simulation when one already is running. There two things that you can do to reduce the number of times that this problem affects your simulations.

Write to Unique Testlogs

Normally COOJA writes a testlog to a path like

    ./contiki/tools/cooja/build/COOJA.testlog

To avoid simultaneous COOJA instances from interferring with each other, modify ScriptRunner.java to include the PID in the file name. One consequence of this change is that many old test logs will accumulate in the /soe/yourlogin/contiki/tools/cooja/build directory. Periodically delete these log files.

You will find scriptRunner.java at a path like

    ./java/org/contikios/cooja/plugins/ScriptRunner.java

Make these changes:

Add an import statement after the other import statements.

    import java.lang.management.ManagementFactory;

After the test for a NULL logWriter, create a filename that includes the PID.

    if (logWriter == null) {
        /* Warning: static variable, used by all active test editor plugins */
        // Create a fileName that includes the PID.
        String PID = ManagementFactory.getRuntimeMXBean().getName().split("@")[0];
        String uniqueFileName = "COOJA." + PID + ".testlog";
        File logFile = new File(uniqueFileName);

Just before the String command[] is created, create a filename that includes the PID.

    // Create a fileName that includes the PID.
    String PID = ManagementFactory.getRuntimeMXBean().getName().split("@")[0];
    String uniqueFileName = "COOJA." + PID + ".testlog";
    final File logFile = new File(coojaBuild, uniqueFileName);

Staggered Starts

If you try to start several background jobs, you may discover that even with the changes mentioned above, there will be interference. To help reduce the likelihood of interference, stagger the starts. For example, you could make a script that starts several background make commands, but delays their initial execution to be 3 minutes apart.

    make -f cmaes1.mak < lotsofnewlines.txt > make1.out &
    sleep 180
    make -f cmaes2.mak < lotsofnewlines.txt > make2.out &
    sleep 180
    make -f cmaes3.mak < lotsofnewlines.txt > make3.out &
    sleep 180
    make -f cmaes4.mak < lotsofnewlines.txt > make4.out &
    sleep 180
    make -f cmaes5.mak < lotsofnewlines.txt > make5.out &
    sleep 180
    make -f cmaes6.mak < lotsofnewlines.txt > make6.out &
    sleep 180
    make -f cmaes7.mak < lotsofnewlines.txt > make7.out &

In this example, each of the different makefiles cmaes#.mak set the “all” target to be a unique lists of simulation targets, and then they include a main makefile that actually defines how to run the simulations.

    .PHONY: all
    all : target1

    include cmaes.mak

Give the Simulation Newlines

This may no longer be needed, but at one time it seems to help by redirecting stdin of each submitted background job to a text file that had several hundred empty lines. Then if the simulation needed someone to press an Enter key, it would continue on.

The makefile example above shows this change.

After making all of these changes, you still may have a few aborted simulations (for me it’s about 4%). So when necessary, I delete any partial log files and rerun make.