realism, but is (marginally) faster.
- \b SMPI: Realistic network model specifically tailored for HPC
settings (accurate modeling of slow start with correction factors on
- three intervals: < 1KiB, < 64 KiB, >= 64 KiB)
+ three intervals: < 1KiB, < 64 KiB, >= 64 KiB). See also \ref
+ options_model_network_coefs "this section" for more info.
- \b CM02: Legacy network analytic model (Very similar to LV08, but
without corrective factors. The timings of small messages are thus
poorly modeled)
- \b ptask_L07: Workstation model somehow similar to Cas01+CM02 but
allowing parallel tasks
-Finally, the network and CPU models that are based on lmm_solve (that
+\subsection options_model_optim Optimization level of the platform models
+
+The network and CPU models that are based on lmm_solve (that
is, all our analytical models) accept specific optimization
-configurations (through the \b network/optim and \b CPU/optim
-variables). The accepted values are (both default to 'Lazy'):
- - \b Lazy: Lazy action management (partial invalidation in lmm +
- heap in action remaining).
- - \b TI: Trace integration. Highly optimized mode when using
- availability traces (only available for the Cas01 CPU model for
- now).
- - \b Full: Full update of remaining and variables. Slow but may be
- useful when debugging.
+configurations.
+ - variables \b network/optim and \b CPU/optim (both default to 'Lazy'):
+ - \b Lazy: Lazy action management (partial invalidation in lmm +
+ heap in action remaining).
+ - \b TI: Trace integration. Highly optimized mode when using
+ availability traces (only available for the Cas01 CPU model for
+ now).
+ - \b Full: Full update of remaining and variables. Slow but may be
+ useful when debugging.
+ - variables \b network/maxmin_selective_update and
+ \b cpu/maxmin_selective_update: configure whether the underlying
+ should be lazily updated or not. It should have no impact on the
+ computed timings, but should speed up the computation.
+
+It is still possible to disable the \c maxmin_selective_update feature
+because it can reveal counter-productive in very specific scenarios
+where the interaction level is high. In particular, if all your
+communication share a given backbone link, you should disable it:
+without \c maxmin_selective_update, every communications are updated
+at each step through a simple loop over them. With that feature
+enabled, every communications will still get updated in this case
+(because of the dependency induced by the backbone), but through a
+complicated pattern aiming at following the actual dependencies.
+
+\subsection options_model_precision Numerical precision of the platform models
+The analytical models handle a lot of floating point values. It is
+possible to change the epsilon used to update and compare them through
+the \b maxmin/precision variable (default value: 1e-9). Changing it
+may speedup the simulation by discarding very small actions, at the
+price of a reduced numerical precision.
\subsection options_model_network Configuring the Network model
-\subsubsection options_model_network_gamma Maximal TCP window size (network/TCP_gamma)
+\subsubsection options_model_network_gamma Maximal TCP window size
The analytical models need to know the maximal TCP window size to take
the TCP congestion mechanism into account. This is set to 20000 by
-default, but can be changed using the network/TCP_gamma variable.
+default, but can be changed using the \b network/TCP_gamma variable.
On linux, this value can be retrieved using the following
commands. Both give a set of values, and you should use the last one,
cat /proc/sys/net/ipv4/tcp_wmem # gives the receiver window
\endverbatim
-\subsubsection options_model_network_crosstraffic Simulating cross-traffic (network/crosstraffic)
+\subsubsection options_model_network_coefs Corrective simulation factors
+
+These factors allow to betterly take the slow start into account.
+The corresponding values were computed through data fitting one the
+timings of packet-level simulators. You should not change these values
+unless you are really certain of what you are doing. See
+<a href="http://mescal.imag.fr/membres/arnaud.legrand/articles/simutools09.pdf">Accuracy Study and Improvement of Network Simulation in the SimGrid Framework</a>
+for more informations about these coeficients.
+
+If you are using the SMPI model, these correction coeficients are
+themselves corrected by constant values depending on the size of the
+exchange. Again, only hardcore experts should bother about this fact.
+
+\subsubsection options_model_network_crosstraffic Simulating cross-traffic
As of SimGrid v3.7, cross-traffic effects can be taken into account in
analytical simulations. It means that ongoing and incoming
This is activated through the \b network/crosstraffic variable, that
can be set to 0 (disable this feature) or 1 (enable it).
-\section options_modelchecking Model-Checking
-\subsection options_modelchecking_howto How to use it
+\subsection options_model_network_coord Coordinated-based network models
+
+When you want to use network coordinates, as it happens when you use
+an \<AS\> in your platform file with \c Vivaldi as a routing, you must
+set the \b network/coordinates to \c yes so that all mandatory
+initialization are done in the simulator.
+
+\subsection options_model_network_sendergap Simulating sender gap
+
+(this variable is experimental and may change or disapear)
+
+It is possible to specify a timing gap between consecutive emission on
+the same network card through the \b network/sender_gap variable. This
+is still under investigation as of writting, and the default value is
+to wait 0 seconds between emissions (no gap applied).
+
+\section options_modelchecking Model-Checking specific configuration variables
+
To enable the experimental SimGrid model-checking support the program should
be executed with the command line argument
\verbatim
void MC_assert(int prop);
\endverbatim
+\section options_virt User process virtualization options
+
+\subsection options_virt_factory Selecting the virtualization factory
+
+In SimGrid, the user code is virtualized in a specific mecanism
+allowing the simulation kernel to control its execution: when a user
+process requires a blocking action (such as sending a message), it is
+interrupted, and only gets released when the simulated clock reaches
+the point where the blocking operation is done.
+
+In SimGrid, the containers in which user processes are virtualized are
+called contexts. Several context factory are provided, and you can
+select the one you want to use with the \b contexts/factory
+configuration variable. Some of the following may not exist on your
+machine because of portability issues. In any case, the default one
+should be the most effcient one (please report bugs if the
+auto-detection fails for you). They are sorted here from the slowest
+to the most effient:
+ - \b thread: very slow factory using full featured threads (either
+ ptheads or windows native threads)
+ - \b ucontext: fast factory using System V contexts (or a portability
+ layer of our own on top of Windows fibers)
+ - \b raw: amazingly fast factory using a context switching mecanism
+ of our own, directly implemented in assembly (only available for x86
+ and amd64 platforms for now)
+
+The only reason to change this setting is when the debuging tools get
+fooled by the optimized context factories. Threads are the most
+debugging-friendly contextes.
+
+\subsection options_virt_stacksize Adapting the used stack size
+
+(this only works if you use ucontexts or raw context factories)
+
+Each virtualized used process is executed using a specific system
+stack. The size of this stack has a huge impact on the simulation
+scalability, but its default value is rather large. This is because
+the error messages that you get when the stack size is too small are
+rather disturbing: this leads to stack overflow (overwriting other
+stacks), leading to segfaults with corrupted stack traces.
+
+If you want to push the scalability limits of your code, you really
+want to reduce the \b contexts/stack_size variable. Its default value
+is 128 (in Kib), while our Chord simulation works with stacks as small
+as 16 Kib, for example.
+
+\subsection options_virt_parallel Running user code in parallel
+
+Parallel execution of the user code is only considered stable in
+SimGrid v3.7 and higher. It is described in
+<a href="http://hal.inria.fr/inria-00602216/">INRIA RR-7653</a>.
+
+If you are using the \c ucontext or \c raw context factories, you can
+request to execute the user code in parallel. Several threads are
+launched, each of them handling as much user contexts at each run. To
+actiave this, set the \b contexts/nthreads variable to the amount of
+core that you have in your computer.
+
+Even if you asked several worker threads using the previous option,
+you can request to start the parallel execution (and pay the
+associated synchronization costs) only if the potential parallelism is
+large enough. For that, set the \b contexts/parallel_threshold
+variable to the minimal amount of user contexts needed to start the
+parallel execution. In any given simulation round, if that amount is
+not reached, the contexts will be run sequentially directly by the
+main thread (thus saving the synchronization costs). Note that this
+option is mainly useful when the grain of the user code is very fine,
+because our synchronization is now very efficient.
+
+When parallel execution is activated, you can choose the
+synchronization schema used with the \b contexts/synchro variable,
+which value is either:
+ - \b futex: ultra optimized synchronisation schema, based on futexes
+ (fast user-mode mutexes), and thus only available on Linux systems.
+ This is the default mode when available.
+ - \b posix: slow but portable synchronisation using only POSIX
+ primitives.
+ - \b busy_wait: not really a synchronisation: the worker threads
+ constantly request new contexts to execute. It should be the most
+ efficient synchronisation schema, but it loads all the cores of your
+ machine for no good reason. You probably prefer the other less
+ eager schemas.
+
+
+
+\section options_generic Various generic configuration variables
+
+\section options_generic_path XML file inclusion path
+
+It is possible to specify a list of directories to search into for the
+\<include\> tag in XML files by using the \b path configuration
+variable. To add several directory to the path, set the configuration
+variable several times, as in \verbatim
+--cfg=path:toto --cfg=path:tutu
+\endverbatim
+
+\section options_generic_exit Behavior on Ctrl-C
+
+By default, when Ctrl-C is pressed, the status of all existing
+simulated processes is displayed. This is very useful to debug your
+code, but it can reveal troublesome in some cases (such as when the
+amount of processes becomes really big). This behavior is disabled
+when \b verbose-exit is set to 0 (it is to 1 by default).
+
+\section options_index Index of all existing variables
+
+- \c contexts/factory: \ref options_virt_factory
+- \c contexts/nthreads: \ref options_virt_parallel
+- \c contexts/parallel_threshold: \ref options_virt_parallel
+- \c contexts/stack_size: \ref options_virt_stacksize
+- \c contexts/synchro: \ref options_virt_parallel
+
+
+- \c cpu/maxmin_selective_update: \ref options_model_optim
+- \c cpu/model: \ref options_model_select
+- \c cpu/optim: \ref options_model_optim
+
+- \c maxmin/precision: \ref options_model_precision
+
+- \c network/bandwidth_factor: \ref options_model_network_coefs
+- \c network/coordinates: \ref options_model_network_coord
+- \c network/crosstraffic: \ref options_model_network_crosstraffic
+- \c network/latency_factor: \ref options_model_network_coefs
+- \c network/maxmin_selective_update: \ref options_model_optim
+- \c network/model: \ref options_model_select
+- \c network/optim: \ref options_model_optim
+- \c network/sender_gap: \ref options_model_network_sendergap
+- \c network/TCP_gamma: \ref options_model_network_gamma
+- \c network/weight_S: \ref options_model_network_coefs
+
+- \c path: \ref options_generic_path
+- \c verbose-exit: \ref options_generic_exit
+
+- \c workstation/model: \ref options_model_select
+
*/
\ No newline at end of file
