may speedup the simulation by discarding very small actions, at the
price of a reduced numerical precision.
+\subsection options_model_nthreads Parallel threads for model updates
+
+By default, Surf computes the analytical models sequentially to share their
+resources and update their actions. It is possible to run them in parallel,
+using the \b surf/nthreads item (default value: 1). If you use a
+negative value, the amount of available cores is automatically
+detected and used instead.
+
+Depending on the workload of the models and their complexity, you may get a
+speedup or a slowdown because of the synchronization costs of threads.
+
\subsection options_model_network Configuring the Network model
\subsubsection options_model_network_gamma Maximal TCP window size
available in <tt>examples/msg/gtnets/crosstraffic-p.xml</tt>.
This is activated through the \b network/crosstraffic item, that
-can be set to 0 (disable this feature) or 1 (enable it).
+can be set to 0 (disable this feature) or 1 (enable it).
+
+Note that with the default workstation model this option is activated by default.
\subsubsection options_model_network_coord Coordinated-based network models
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 item to the amount of
-core that you have in your computer.
+cores that you have in your computer (or -1 to have the amount of cores
+auto-detected).
Even if you asked several worker threads using the previous option,
you can request to start the parallel execution (and pay the
\section options_tracing Configuring the tracing subsystem
-(TODO)
+The \ref tracing "tracing subsystem" can be configured in several
+different ways depending on the nature of the simulator (MSG, SimDag,
+SMPI) and the kind of traces that need to be obtained. See the \ref
+tracing_tracing_options "Tracing Configuration Options subsection" to
+get a detailed description of each configuration option.
+
+We detail here a simple way to get the traces working for you, even if
+you never used the tracing API.
+
+
+- Any SimGrid-based simulator (MSG, SimDag, SMPI, ...) and raw traces:
+\verbatim
+--cfg=tracing:1 --cfg=tracing/uncategorized:1 --cfg=triva/uncategorized:uncat.plist
+\endverbatim
+ The first parameter activates the tracing subsystem, the second
+ tells it to trace host and link utilization (without any
+ categorization) and the third creates a graph configuration file
+ to configure Triva when analysing the resulting trace file.
+
+- MSG or SimDag-based simulator and categorized traces (you need to declare categories and classify your tasks according to them)
+\verbatim
+--cfg=tracing:1 --cfg=tracing/categorized:1 --cfg=triva/categorized:cat.plist
+\endverbatim
+ The first parameter activates the tracing subsystem, the second
+ tells it to trace host and link categorized utilization and the
+ third creates a graph configuration file to configure Triva when
+ analysing the resulting trace file.
+
+- SMPI simulator and traces for a space/time view:
+\verbatim
+smpirun -trace ...
+\endverbatim
+ The <i>-trace</i> parameter for the smpirun script runs the
+simulation with --cfg=tracing:1 and --cfg=tracing/smpi:1. Check the
+smpirun's <i>-help</i> parameter for additional tracing options.
\section options_smpi Configuring SMPI
- \c ns3/TcpModel: \ref options_pls
+- \c surf/nthreads: \ref options_model_nthreads
+
- \c smpi/running_power: \ref options_smpi_bench
- \c smpi/display_timing: \ref options_smpi_timing
- \c smpi/cpu_threshold: \ref options_smpi_bench
