University of Duisburg-Essen /
Institute for Experimental Mathematics /
Computer Networking Technology Group
Homepage of Thomas Dreibholz /
SimProcTC Homepage
University of Duisburg-Essen /
Institute for Experimental Mathematics /
Computer Networking Technology Group
Homepage of Thomas Dreibholz /
SimProcTC Homepage
New release: simproctc-2.0.1.
New release: simproctc-2.0.0.
After a long time, this page has been refurbished. An up-to-date version of SimProcTC is coming soon, working with the latest OMNeT++ 6.0!
In order to efficiently perform simulations using my RSerPool simulation model RSPSIM as well as simulations with the CMT-SCTP model in the INET Framework, I have also developed a model-independent, flexible and powerful tool-chain for the setup, parallel run execution, results aggregation, data analysis and debugging – completely based on Open Source software: SimProcTC (Simulation Processing Tool-Chain). Due to its independence of a specific model, it may also be useful for many more users of OMNeT++. Therefore, I have released this tool-chain as Open Source under GPLv3 license.
A detailed description of SimProcTC can be found in Appendix B of ``Evaluation and Optimisation of Multi-Path Transport using the Stream Control Transmission Protocol´´. Some further information on SimProcTC can also be found in the following references:
The complete BibTeX references in a single file can be found here!
Dreibholz, Thomas: ``Evaluation and Optimisation of Multi-Path Transport using the Stream Control Transmission Protocol´´ (PDF, 36779 KiB, 🇬🇧), Habilitation Treatise, University of Duisburg-Essen, Faculty of Economics, Institute for Computer Science and Business Information Systems, URN urn:nbn:de:hbz:464-20120315-103208-1, March 13, 2012, [BibTeX, XML].
Keywords: Stream Control Transmission Protocol (SCTP), Multi-Path Transport, Dissimilar Paths, Fairness, Evaluation, Optimisation
Abstract: The Stream Control Transmission Protocol (SCTP) as defined in RFC 4960 is an advanced Transport Layer protocol that provides support for multi-homing. That is, SCTP endpoints may simultaneously use multiple Network Layer addresses, which allows to connect the endpoints to multiple networks for redundancy purposes. However, for the transfer of user data, only one of the possible paths is currently used at a time. All other paths remain as backup and are only used for retransmissions. Clearly, the existence of multiple paths has led to the idea of applying load sharing among the paths. An extension to SCTP – denoted as Concurrent Multipath Transfer (CMT) – realises this load sharing functionality. While this approach works well for similar paths, i.e. paths having similar characteristics regarding bandwidths, bit error rates and delays, the use of dissimilar paths does not work that neatly. In this thesis, the issues of dissimilar paths for CMT-based load sharing will be demonstrated first. The reasons for these issues will be identified and solutions proposed. These solutions will be evaluated in simulations, as well as partially also in a real-world Internet testbed setup, in order to show their effectiveness. In particular, it will be shown that a combination of multiple mechanisms is necessary to make CMT work as expected under a wide range of network and system parameters. Furthermore, the fairness of CMT-based transport – in concurrency to classic non-CMT flows – will be analysed. The usage of plain CMT leads to an overly aggressive bandwidth occupation on so-called shared bottlenecks. As a countermeasure, the idea of Resource Pooling will be utilised. For this purpose, two new and one adapted congestion control approach – all based on the Resource Pooling principle – will be introduced and examined in similar as well as dissimilar path setups, in order to show how to fairly deploy CMT transport in the Internet. The results of this work have also been contributed to the ongoing IETF standardisation process of SCTP and its extensions.
URL: https://duepublico.uni-duisburg-essen.de/servlets/DerivateServlet/Derivate-29737/Dre2012_final.pdf
MD5: add34f0b780cb35b7ee1f963ea85e59c
Dreibholz, Thomas; Zhou, Xing and Rathgeb, Erwin Paul: ``SimProcTC – The Design and Realization of a Powerful Tool-Chain for OMNeT++ Simulations´´ (PDF, 552 KiB, 🇬🇧), in Proceedings of the 2nd ACM/ICST International Workshop on OMNeT++, pp. 1–8, DOI 10.4108/ICST.SIMUTOOLS2009.5517, ISBN 978-963-9799-45-5, Rome/Italy, March 6, 2009, [BibTeX, XML].
Keywords: SimProcTC, Simulation, Parametrization, Run Distribution, Results Visualization
Abstract: In this paper, we introduce our Open Source simulation tool-chain for OMNeT++ simulations: SimProcTC. This model-independent tool-chain has been designed to perform the common and frequently recurring tasks of simulation work – which are the parametrization of runs, the distributed run processing and the results visualization – in an efficient and easy to use manner. It is already successfully deployed for several OMNeT++-based research projects.
MD5: 1ec4aec2824e6f4d11f1e1af9a8d3991
Dreibholz, Thomas and Rathgeb, Erwin Paul: ``A Powerful Tool-Chain for Setup, Distributed Processing, Analysis and Debugging of OMNeT++ Simulations´´ (PDF, 558 KiB, 🇬🇧), in Proceedings of the 1st ACM/ICST International Workshop on OMNeT++, DOI 10.4108/ICST.SIMUTOOLS2008.2990, ISBN 978-963-9799-20-2, Marseille, Bouches-du-Rhône/France, March 7, 2008, [BibTeX, XML].
Keywords: SimProcTC, Simulation Model, Parametrization, Simulation Run Distribution, Plotting, Analysis
Abstract: In this paper, we introduce our Open Source tool-chain providing the parametrization, distributed execution, results post-processing and debugging for OMNeT++-based simulations. While the initial motivation of these tools has been the support of our simulation model of the Reliable Server Pooling (RSerPool) framework, it has been particularly designed with model-independence in mind. That is, it can be easily adapted to other simulation models and therefore may be useful for other users of OMNeT++-based simulation models as well.
MD5: 23f563d708ab1eb3f55d6dd21ef4eee4
Dreibholz, Thomas: ``Reliable Server Pooling – Evaluation, Optimization and Extension of a Novel IETF Architecture´´ (PDF, 9080 KiB, 🇬🇧), Ph.D. Dissertation, University of Duisburg-Essen, Faculty of Economics, Institute for Computer Science and Business Information Systems, URN urn:nbn:de:hbz:465-20070308-164527-0, March 7, 2007, [BibTeX, XML]. Awarded with the Science Award of the Sparkasse Essen.
Keywords: Reliable Server Pooling (RSerPool), Evaluation, Optimization, Extension
Abstract: The Reliable Server Pooling (RSerPool) architecture currently under standardization by the IETF RSerPool Working Group is an overlay network framework to provide server replication and session failover capabilities to applications using it. These functionalities as such are not new, but their combination into one generic, application-independent framework is. Initial goal of this thesis is to gain insight into the complex RSerPool mechanisms by performing experimental and simulative proof-of-concept tests. The further goals are to systematically validate the RSerPool architecture and its protocols, provide improvements and optimizations where necessary and propose extensions if useful. Based on these evaluations, recommendations to implementers and users of RSerPool should be provided, giving guidelines for the tuning of system parameters and the appropriate configuration of application scenarios. In particular, it is also a goal to transfer insights, optimizations and extensions of the RSerPool protocols from simulation to reality and also to bring the achievements from research into application by supporting and contributing relevant results to the IETF's ongoing RSerPool standardization process. To achieve the described goals, a prototype implementation as well as a simulation model are designed and realized at first. Using a generic application model and appropriate performance metrics, the performance of RSerPool systems in failure-free and server failure scenarios is systematically evaluated in order to identify critical parameter ranges and problematic protocol behaviour. Improvements developed as result of these performance analyses are evaluated and finally contributed into the standardization process of RSerPool.
URL: https://duepublico.uni-duisburg-essen.de/servlets/DerivateServlet/Derivate-16326/Dre2006_final.pdf
MD5: acdd102ebd0775ca5de523ec5710d800
The following items are a step-by-step installation guide for SimProcTC.
Get the latest version of OMNeT++ here and install it under Linux. If you do not have Linux installed already, you may find my Little Ubuntu Linux Installation Guide helpful. This installation guide also provides help on how to install OMNeT++ on an Ubuntu system.
Note that while OMNeT++ also works under Microsoft Windows, my tool-chain has not been tested under this operating system yet. In particular, run distribution using RSerPool will not work under Windows unless you port the RSPLIB RSerPool implementation to Windows.
After installing OMNeT++, make sure that it is working properly.
Install GNU R. Usually, it will be available for your Linux distribution as installation package. However, if you decide to install it from source, you can download the source here.
Under Ubuntu/Debian Linux, you can download and install GNU R using the following command line:
sudo apt-get install r-base r-base-html r-base-latex r-base-dev r-doc-info r-doc-pdf r-doc-html r-mathlib
After installation, you can start GNU R by:
R --vanilla
You can quit GNU R using Ctrl+D.
The simulation tool-chain requires LIBBZ2 for compression and decompression of files. In particular, also the developer files (include files) of this library are required to compile the tool-chain. Usually, it will be available for your Linux distribution as installation package. However, if you decide to install it from source, you can download the source here.
Under Ubuntu/Debian Linux, you can download and install LIBBZ2 using the following command line:
sudo apt-get install libbz2-dev
Get the simulation tool-chain package from the Sources Download section and unpack it. Also read the description paper in the docs/ directory; it gives important information on what the tool-chain actually does! The tool-chain archive includes the files of the tool chain as well as a small example simulation. The files have the following purposes:
In order to compile tool-chain and examples, call the following commands in the corresponding example-simulation subdirectory:
opp_makemake -f make cd tools make cd ..
Make sure that everything compiles successfully. Otherwise, the tool-chain will not work properly! After compilation, you can start the demo simulation by calling:
./example-simulatio
The example simulation packaged with SimProcTC simply presents the effects of fragmenting large packets into cells and forwarding them: the delays will significantly reduce at the price of increased overhead. Have a look into scenario.ned to see the parameters of the model:
An example simulation for this model is defined in test1.R: for each parameter of the model, the list "simulationConfigurations" contains a list with the parameter name as first element and its value(s) as further elements. For example, list("sourcePayloadSize", 1000, 2500) means that the parameter "sourcePayloadSize" should be used with the values 1000 bytes and 2500 bytes. For each parameter combination, a separate run will be created. Furthermore, the variable "simulationRuns" specifies how many different seeds should be used. That is, for simulationRuns=3, runs for each parameter combinations are created with 3 different seeds (i.e. tripling the number of runs!).
The actual output of .ini files is realized in simulate-version1.R. Have a look over this file first, it should be quite self-explaining! In the function demoWriteParameterSection(), the actual lines for the parameters above are written for each simulation run. "simCreatorAdditionalActiveVariables" defines for which variables a table row should always be written. For example, if you always use cellHeaderSize=4, the createsummary script would neglect this parameter in the output table. Since it may be useful for your post-processing, you can add it to "simCreatorAdditionalActiveVariables". Note, that "simCreatorWriteParameterSection" is set to "demoWriteParameterSection". In the generic simulation.R script, always the names simCreatorXXX instead of demoXXX are used. In order to be model-independent, it is necessary to set these variables to the actual model-dependent functions in simulate-version1.R! When you adapt the tool-chain to you own model, you only have to create your own simulation-versionX.R script and leave the other scripts unmodified.
The variables "distributionPool" and "distributionProcs" in test1.R are used to control the request distribution. They will be explained later. For now, make sure that distributionProcs is set to 0! This setting means that all runs are processed on the local machine.
Now, in order to perform the simulation defined in test1.R, simply execute test1.R using R:
R --vanilla < test1.R
The script will now create an .ini file for each run and a Makefile containing all runs. Finally, "make" will be called to process the created Makefile. "make" will already be called with the -j parameter corresponding to your number of CPUs/cores, so that it fully utilizes the computation power of your machine. You can observe the progress of the simulation processing by monitoring the log file:
tail -f test1/make.log
You can abort the simulation processing and continue later. Only the run(s) currently in progress are lost and have to be re-processed upon resumption. Already completed runs are saved and no re-processing is necessary.
After processing the simulation defined by test1.R, you can plot the results using plot-test1.R:
R --vanilla < plot-test1.R
The results will be written to test1.pdf (the file name will be the simulation output directory + .pdf). You can view it with any PDF reader, e.g. Okular. The plotter settings at the head of plot-test1.R should be almost self-explaining. For "colorMode", you can also use cmBlackAndWhite or cmGreyScale. Setting "plotOwnOutput" to TRUE results in an own output file for each plot (instead of a single PDF file). "plotConfigurations" contains the definitions for each plot, in particular title, output file name for "plotOwnOutput", x- and y-axis ticks, legend position and the results data for each axis given by a template. A set of model-specific templates is already defined in simulate-version1.R, you can add additional ones there or to "plotVariables" in plot-test1.R. See also the paper for more details on templates.
Make sure that the previous steps (performing simulations and plotting) work. If they are not working properly, the run distribution will also fail! First, it is necessary to install the RSPLIB RSerPool implementation. On a Ubuntu system, RSPLIB can be installed directly using APT:
sudo apt-get install rsplib-registrar rsplib-services rsplib-tools
In case of a need for a manual installation, also see the RSPLIB Handbook here!
One one computer, run CSP monitor to display the status of the other components:
cspmonitor
Note the IP address of this system. The CSP monitor runs on UDP port 2960.
For the other components to be started, define environment variables:
export CSP_SERVER=<IP_OF_CSP_MONITOR>:2960 export CSP_INTERVAL=333
You can put these commands e.g. into ~/.bashrc, so that the variables are available in all new shell instances!
In your network, start at least one RSerPool Pool Registrar (PR):
rspregistrar
With the environment variables above set correctly, the CSP monitor should show the registrar.
Then, start a Scripting Service Pool Element (PE) in another shell.
rspserver -scripting -policy=LeastUsed -ssmaxthreads=4
The parameter -ssmaxthreads specifies the number of parallel sessions; use the number of cores/CPUs in your machine). The output of "rspserver" should look as follows:
Starting service ...
Scripting Server - Version 2.0
==============================
General Parameters:
Pool Handle = ScriptingPool
Reregistration Interval = 30.000s
Local Addresses = { all }
Runtime Limit = off
Max Threads = 4
Policy Settings
Policy Type = LeastUsed
Load Degradation = 0.000%
Load DPF = 0.000%
Weight = 0
Weight DPF = 0.000%
Scripting Parameters:
Keep Temp Dirs = no
Verbose Mode = no
Transmit Timeout = 30000 [ms]
Keep-Alive Interval = 15000 [ms]
Keep-Alive Timeout = 10000 [ms]
Cache Max Size = 131072 [KiB]
Cache Max Entries = 16
Cache Directory =
Keyring =
Trust DB =
Registration:
Identifier = $249c7176
In particular, take care of the "Identifier" line. This is the ID of the pool element under which it has been registered. If there are error messages saying that registration has failed, etc., have a look into the RSPLIB handbook. Usually, this means a small configuration problem which can be solved easily! It may also be helpful to use Wireshark for debugging network issues; it has dissectors for the RSerPool protocols as well as for CSP and the Scripting Service protocols!
With the environment variables above set correctly, the CSP monitor should show the PE.
Have a look into the script ssdistribute. Ensure that the variable setting for SIMULATION_POOLUSER points to the executable scriptingclient of the RSPLIB package (if installed from the Ubuntu package: /usr/bin/scriptingclient). If scriptingclient is located elsewhere, e.g. src/rsplib-3.3.2/src in your home directory, the line should be:
SIMULATION_POOLUSER=~/src/rsplib-3.3.2/src/scriptingclient
In test1.R, set "distributionProcs" to the maximum number of simultaneous sessions (at least 1; if you later start 5 pool elements with 2 cores each, you should use 10). It is safe to use 1 for the following test. After modifying "distributionProcs", increase "simulationRuns" e.g. by 1. Otherwise, since you have already performed the run of test1.R before, no more runs would be necessary (since their results are already there!). Now, run test1.R again:
R --vanilla < test1.R
Have a look at the output of "rspserver": it should receive jobs and process them. Also, have a look at the log output:
tail -f test1/make.log
When the job distribution is working properly, you can start more pool elements and set up your simulation computation pool. Do not forget to increase "distributionProcs" accordingly!
With the environment variables above set correctly, the CSP monitor should show the status of pool users and pool elements during the simulation processing.
The workload distribution system works as follows:
The Makefile first generates a Tar/BZip2 file simulation-environment.tar.bz2 in the simulation directory. It contains the simulation binary, all shared libraries it needs (found out by the get-libs script), all .ned files it needs (found out by the get-neds script) and the script simulation.config-stage0 which sets two environment variables: SIMULATION_PROGRAM contains the name of the binary, SIMULATION_LIBS contains the location of the libraries. If your simulation needs additional files, they can be specified by the variable simulationMiscFiles in simulate-version1.R.
"ssdistribute" – which is called to actually distribute a run to a pool – creates the Tar/GZip file for the run. This file includes the environment file (i.e. usually simulation-environment.tar.bz2) specified by the variable SIMULATION_ENVIRONMENT and additional configuration files like simulation.config-stage0 (but named simulation.config-stage1, simulation.config-stage2, ...) specified by the environment variable SIMULATION_CONFIGS. You have to set these two environment variables in the ssdistribute script. Furthermore, the Tar/GZip file of the run contains the .ini file for the run.
"ssrun" performs a run on a (usually) remote node. First, it finds all simulation.config-stageX scripts and executes them in alphabetical order. That is, simulation.config-stage1 may overwrite settings of simulation.config-stage0 and so on. After that, it looks for .ini files. For each .ini file, it runs the program specified by the environemnt variable SIMULATION_PROGRAM. If the variable SIMULATION_LIBS is set, does not call the binary directly but tells the shared library loader to do this and use the specified set of shared libraries.
If everything went well, a status file is created. The existence of this status file means that the run has been successful.
Finding out what is going wrong with the remote execution can be difficult sometimes. In such a case, only start a single instance of "rspserver" and use the parameter "-sskeeptempdirs". This parameter results in not deleting the temporary session directory after shutdown of the session. That is, you can dissect the directory's contents for troubleshooting. The name of the directory for each session is shown in the output of "rspserver".
In order to use SimProcTC with your own model, perform the following tasks:
Before using the RSerPool-based run distribution, first test your simulation on your local machine! This makes finding problems much easier. If everything works, you can continue with run distribution. If you discover problems or difficulties with the load distribution or RSPLIB, write to the RSPLIB General Discussion List. It is also strongly recommended to subscribe to the RSPLIB Announcement List:
SimProcTC is released under the GNU General Public Licence (GPL).
Please use the issue tracker at https://github.com/dreibh/simproctc/issues to report bugs and issues!
The Git repository of the SimProcTC sources can be found at https://github.com/dreibh/simproctc:
Issue tracker: https://github.com/dreibh/simproctc/issues.
Please submit bug reports, issues, questions, etc. in the issue tracker!
Pull Requests for SimProcTC: https://github.com/dreibh/simproctc/pulls.
Your contributions to SimProcTC are always welcome!
The tarball has been signed with my GnuPG key 21412672518D8B2D1862EFEF5CD5D12AA0877B49. Its authenticity and integrity can be verified by:
gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 21412672518D8B2D1862EFEF5CD5D12AA0877B49 gpg --verify simproctc-<VERSION>.tar.gz.asc simproctc-<VERSION>.tar.gz
The tarballs have been signed with my GnuPG key 21412672518D8B2D1862EFEF5CD5D12AA0877B49. Its authenticity and integrity can be verified by:
gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 21412672518D8B2D1862EFEF5CD5D12AA0877B49 gpg --verify simproctc-<VERSION>.tar.gz.asc simproctc-<VERSION>.tar.gz
