type the following on the command-line:
.. code-block:: shell
-
+
my_simulator --cfg=Item:Value (other arguments)
Several ``--cfg`` command line arguments can naturally be used. If you
file:
.. code-block:: xml
-
+
<config>
<prop id="Item" value="Value"/>
</config>
with :cpp:func:`simgrid::s4u::Engine::set_config` or :cpp:func:`MSG_config`.
.. code-block:: cpp
-
+
#include <simgrid/s4u.hpp>
int main(int argc, char *argv[]) {
simgrid::s4u::Engine e(&argc, argv);
-
+
e->set_config("Item:Value");
-
+
// Rest of your code
}
.. _options_list:
-
+
Existing Configuration Items
----------------------------
models for all existing resources.
- ``network/model``: specify the used network model. Possible values:
-
+
- **LV08 (default one):** Realistic network analytic model
(slow-start modeled by multiplying latency by 13.01, bandwidth by
.97; bottleneck sharing uses a payload of S=20537 for evaluating
RTT). Described in `Accuracy Study and Improvement of Network
Simulation in the SimGrid Framework
- <http://mescal.imag.fr/membres/arnaud.legrand/articles/simutools09.pdf>`_.
+ <http://mescal.imag.fr/membres/arnaud.legrand/articles/simutools09.pdf>`_.
- **Constant:** Simplistic network model where all communication
take a constant time (one second). This model provides the lowest
realism, but is (marginally) faster.
<ftp://ftp.ens-lyon.fr/pub/LIP/Rapports/RR/RR2002/RR2002-40.ps.gz>`_.
- **Reno/Reno2/Vegas:** Models from Steven H. Low using lagrange_solve instead of
lmm_solve (experts only; check the code for more info).
- - **NS3** (only available if you compiled SimGrid accordingly):
+ - **NS3** (only available if you compiled SimGrid accordingly):
Use the packet-level network
simulators as network models (see :ref:`pls_ns3`).
This model can be :ref:`further configured <options_pls>`.
-
+
- ``cpu/model``: specify the used CPU model. We have only one model
for now:
allow parallel tasks because these beasts need some collaboration
between the network and CPU model. That is why, ptask_07 is used by
default when using SimDag.
-
+
- **default:** Default host model. Currently, CPU:Cas01 and
network:LV08 (with cross traffic enabled)
- **compound:** Host model that is automatically chosen if
configurations.
- items ``network/optim`` and ``cpu/optim`` (both default to 'Lazy'):
-
+
- **Lazy:** Lazy action management (partial invalidation in lmm +
heap in action remaining).
- **TI:** Trace integration. Highly optimized mode when using
now).
- **Full:** Full update of remaining and variables. Slow but may be
useful when debugging.
-
+
- items ``network/maxmin-selective-update`` and
``cpu/maxmin-selective-update``: configure whether the underlying
should be lazily updated or not. It should have no impact on the
and you should use the last one, which is the maximal size.
.. code-block:: shell
-
+
cat /proc/sys/net/ipv4/tcp_rmem # gives the sender window
cat /proc/sys/net/ipv4/tcp_wmem # gives the receiver window
.. _cfg=network/bandwidth-factor:
.. _cfg=network/latency-factor:
.. _cfg=network/weight-S:
-
+
Correcting Important Network Parameters
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
computations. More details in @ref plugin_energy.
- **link_energy:** keeps track of the energy dissipated by
communications. More details in @ref SURF_plugin_energy.
- - **host_load:** keeps track of the computational load.
+ - **host_load:** keeps track of the computational load.
More details in @ref plugin_load.
.. _options_modelchecking:
-
+
Configuring the Model-Checking
------------------------------
be executed using the simgrid-mc wrapper:
.. code-block:: shell
-
+
simgrid-mc ./my_program
Safety properties are expressed as assertions using the function
:cpp:func:`void MC_assert(int prop)`.
.. _cfg=model-check/property:
-
+
Specifying a liveness property
..............................
.. code-block:: shell
-
+
simgrid-mc ./my_program --cfg=model-check/property:<filename>
.. _cfg=model-check/checkpoint:
-
+
Going for Stateful Verification
...............................
interrupted, and only gets released when the simulated clock reaches
the point where the blocking operation is done. This is explained
graphically in the `relevant tutorial, available online
-<http://simgrid.gforge.inria.fr/tutorials/simgrid-simix-101.pdf>`_.
+<https://simgrid.org/tutorials/simgrid-simix-101.pdf>`_.
In SimGrid, the containers in which user processes are virtualized are
called contexts. Several context factory are provided, and you can
raw implementation.
|br| Install the relevant library (e.g. with the
libboost-contexts-dev package on Debian/Ubuntu) and recompile
- SimGrid.
+ SimGrid.
- **raw:** amazingly fast factory using a context switching mechanism
of our own, directly implemented in assembly (only available for x86
and amd64 platforms for now) and without any unneeded system call.
If you want to push the scalability limits of your code, you might
want to reduce the ``contexts/stack-size`` item. Its default value is
8192 (in KiB), while our Chord simulation works with stacks as small
-as 16 KiB, for example. For the thread factory, the default value is
-the one of the system but you can still change it with this parameter.
+as 16 KiB, for example. This *setting is ignored* when using the
+thread factory. Instead, you should compile SimGrid and your
+application with ``-fsplit-stack``. Note that this compilation flag is
+not compatible with the model-checker right now.
The operating system should only allocate memory for the pages of the
stack which are actually used and you might not need to use this in
**Option** ``contexts/guard-size`` **Default** 1 page in most case (0 pages on Windows or with MC)
-A stack guard page is usually used which prevents the stack of a given
-actor from overflowing on another stack. But the performance impact
-may become prohibitive when the amount of actors increases. The
-option ``contexts/guard-size`` is the number of stack guard pages
-used. By setting it to 0, no guard pages will be used: in this case,
-you should avoid using small stacks (with :ref:`contexts/stack-size
-<cfg=contexts/stack-size>`) as the stack will silently overflow on
-other parts of the memory.
+Unless you use the threads context factory (see
+:ref:`cfg=contexts/factory`), a stack guard page is usually used
+which prevents the stack of a given actor from overflowing on another
+stack. But the performance impact may become prohibitive when the
+amount of actors increases. The option ``contexts/guard-size`` is the
+number of stack guard pages used. By setting it to 0, no guard pages
+will be used: in this case, you should avoid using small stacks (with
+:ref:`contexts/stack-size <cfg=contexts/stack-size>`) as the stack
+will silently overflow on other parts of the memory.
When no stack guard page is created, stacks may then silently overflow
on other parts of the memory if their size is too small for the
.. _cfg=contexts/nthreads:
.. _cfg=contexts/parallel-threshold:
.. _cfg=contexts/synchro:
-
+
Running User Code in Parallel
.............................
your machine for no good reason. You probably prefer the other less
eager schemas.
-
Configuring the Tracing
-----------------------
- SMPI simulator and traces for a space/time view:
.. code-block:: shell
-
+
smpirun -trace ...
The `-trace` parameter for the smpirun script runs the simulation
- Add the contents of a textual file on top of the trace file as comment:
.. code-block:: shell
-
+
--cfg=tracing/comment-file:my_file_with_additional_information.txt
Please, use these two parameters (for comments) to make reproducible
application, the variable ``smpi/simulate-computation`` should be set
to no. This option just ignores the timings in your simulation; it
still executes the computations itself. If you want to stop SMPI from
-doing that, you should check the SMPI_SAMPLE macros, documented in
+doing that, you should check the SMPI_SAMPLE macros, documented in
Section :ref:`SMPI_adapting_speed`.
+------------------------------------+-------------------------+-----------------------------+
| Solution | Computations executed? | Computations simulated? |
-+====================================+=========================+=============================+
++====================================+=========================+=============================+
| --cfg=smpi/simulate-computation:no | Yes | Never |
+------------------------------------+-------------------------+-----------------------------+
| --cfg=smpi/cpu-threshold:42 | Yes, in all cases | If it lasts over 42 seconds |
http://simgrid.gforge.inria.fr/contrib/smpi-saturation-doc.html
.. _cfg=smpi/display-timing:
-
+
Reporting Simulation Time
.........................
increase the latency, i.e., values larger than or equal to 1 are valid here.
.. _cfg=smpi/papi-events:
-
+
Trace hardware counters with PAPI
.................................
files (See Section :ref:`tracing_tracing_options`).
.. warning::
-
+
This feature currently requires superuser privileges, as registers
are queried. Only use this feature with code you trust! Call
smpirun for instance via ``smpirun -wrapper "sudo "
use. Example:
.. code-block:: shell
-
+
ldd allpairf90
...
libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007fbb4d91b000)
Then, it can be deallocated by calling SMPI_SHARED_FREE(mem).
When smpi/shared-malloc:global is used, the memory consumption problem
-is solved, but it may induce too much load on the kernel's pages table.
+is solved, but it may induce too much load on the kernel's pages table.
In this case, you should use huge pages so that we create only one
entry per Mb of malloced data instead of one entry per 4k.
To activate this, you must mount a hugetlbfs on your system and allocate
at least one huge page:
.. code-block:: shell
-
+
mkdir /home/huge
sudo mount none /home/huge -t hugetlbfs -o rw,mode=0777
sudo sh -c 'echo 1 > /proc/sys/vm/nr_hugepages' # echo more if you need more
to issue if your application contains such a loop:
.. code-block:: cpp
-
+
while(MPI_Wtime() < some_time_bound) {
/* some tests, with no communication nor computation */
}
set variable simgrid::simix::breakpoint = 3.1416
.. _cfg=verbose-exit:
-
+
Behavior on Ctrl-C
..................