X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/4e6e3fd353bb1f033114b4aea12df80743e92838..7f4f03348bd07609e258eb3b545bdafc2c881847:/doc/doxygen/options.doc diff --git a/doc/doxygen/options.doc b/doc/doxygen/options.doc index 18e80381eb..3bc5f7b636 100644 --- a/doc/doxygen/options.doc +++ b/doc/doxygen/options.doc @@ -1,4 +1,4 @@ -/*! \page options Simgrid options and configurations +/*! \page options Step 2: Configure SimGrid A number of options can be given at runtime to change the default SimGrid behavior. For a complete list of all configuration options @@ -9,6 +9,8 @@ report so that we can fix it. Note that some of the options presented here may not be available in your simulators, depending on the @ref install_src_config "compile-time options" that you used. +\tableofcontents + \section options_using Passing configuration options to the simulators There is several way to pass configuration options to the simulators. @@ -92,7 +94,7 @@ described in - \b LV08 (default one): Realistic network analytic model (slow-start modeled by multiplying latency by 10.4, bandwidth by .92; bottleneck sharing uses a payload of S=8775 for evaluating RTT) - - \b Constant: Simplistic network model where all communication + - \anchor options_model_select_network_constant \b Constant: Simplistic network model where all communication take a constant time (one second). This model provides the lowest realism, but is (marginally) faster. - \b SMPI: Realistic network model specifically tailored for HPC @@ -118,8 +120,6 @@ If you compiled SimGrid accordingly, you can use packet-level network simulators as network models (see \ref pls). In that case, you have two extra models, described below, and some \ref options_pls "specific additional configuration flags". - - \b GTNets: Network pseudo-model using the GTNets simulator instead - of an analytic model - \b NS3: Network pseudo-model using the NS3 tcp model instead of an analytic model @@ -263,7 +263,7 @@ phenomena such as ack compression. For that to work, your platform must have two links for each pair of interconnected hosts. An example of usable platform is -available in examples/msg/gtnets/crosstraffic-p.xml. +available in examples/platforms/crosstraffic.xml. This is activated through the \b network/crosstraffic item, that can be set to 0 (disable this feature) or 1 (enable it). @@ -273,7 +273,8 @@ Note that with the default host model this option is activated by default. \subsubsection options_model_network_coord Coordinated-based network models When you want to use network coordinates, as it happens when you use -an \ in your platform file with \c Vivaldi as a routing, you must +an \ in your platform file with \c Vivaldi as a routing (see also +Section \ref pf_routing_model_vivaldi "Vivaldi Routing Model"), you must set the \b network/coordinates to \c yes so that all mandatory initialization are done in the simulator. @@ -293,7 +294,7 @@ to wait 10 microseconds (1e-5 seconds) between emissions. It is possible to specify that messages below a certain size will be sent as soon as the call to MPI_Send is issued, without waiting for the correspondant receive. This threshold can be configured through the -\b smpi/async_small_thres item. The default value is 0. This behavior can also be +\b smpi/async_small_thresh item. The default value is 0. This behavior can also be manually set for MSG mailboxes, by setting the receiving mode of the mailbox with a call to \ref MSG_mailbox_set_async . For MSG, all messages sent to this mailbox will have this behavior, so consider using two mailboxes if needed. @@ -316,19 +317,12 @@ corresponding to the ns3::TcpL4Protocol::SocketType configuration item in NS3. The only valid values (enforced on the SimGrid side) are 'NewReno' or 'Reno' or 'Tahoe'. -When using GTNeTS, two items exist: - - \b gtnets/jitter, that is a double value to oscillate - the link latency, uniformly in random interval - [-latency*gtnets_jitter,latency*gtnets_jitter). It defaults to 0. - - \b gtnets/jitter_seed, the positive seed used to reproduce jitted - results. Its value must be in [1,1e8] and defaults to 10. - \section options_modelchecking Configuring the Model-Checking -To enable the experimental SimGrid model-checking support the program should -be executed with the command line argument +To enable the SimGrid model-checking support the program should +be executed using the simgrid-mc wrapper: \verbatim ---cfg=model-check:1 +simgrid-mc ./my_program \endverbatim Safety properties are expressed as assertions using the function @@ -347,10 +341,6 @@ ltl2ba program. --cfg=model-check/property: \endverbatim -Of course, specifying a liveness property enables the model-checking -so that you don't have to give --cfg=model-check:1 in -addition. - \subsection options_modelchecking_steps Going for stateful verification By default, the system is backtracked to its initial state to explore @@ -368,9 +358,6 @@ setting for your specific system. --cfg=model-check/checkpoint:1 \endverbatim -Of course, specifying this option enables the model-checking so that -you don't have to give --cfg=model-check:1 in addition. - \subsection options_modelchecking_reduction Specifying the kind of reduction The main issue when using the model-checking is the state space @@ -391,10 +378,6 @@ For now, this configuration variable can take 2 values: * dpor: Apply Dynamic Partial Ordering Reduction. Only valid if you verify local safety properties. -Of course, specifying a reduction technique enables the model-checking -so that you don't have to give --cfg=model-check:1 in -addition. - \subsection options_modelchecking_visited model-check/visited, Cycle detection In order to detect cycles, the model-checker needs to check if a new explored @@ -551,8 +534,8 @@ phase. \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 +In SimGrid, the user code is virtualized in a specific mechanism +that allows 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. @@ -572,6 +555,10 @@ to the most effient: - \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) + - \b boost: This uses the [context implementation](http://www.boost.org/doc/libs/1_59_0/libs/context/doc/html/index.html) + of the boost library; you must have this library installed before + you compile SimGrid. (On Debian GNU/Linux based systems, this is + provided by the libboost-contexts-dev package.) The only reason to change this setting is when the debugging tools get fooled by the optimized context factories. Threads are the most @@ -765,7 +752,7 @@ be simulated using SMPI by calling internal smpi_execute*() functions. To disable the benchmarking/simulation of computation in the simulated application, the variable \b -smpi/simulation_computation should be set to no +smpi/simulate_computation should be set to no \subsection options_model_smpi_bw_factor smpi/bw_factor: Bandwidth factors @@ -793,10 +780,10 @@ Here, MAX_BANDWIDTH denotes the bandwidth of the link. \b Default: 0 (false) -Most of the time, you run MPI code through SMPI to compute the time it -would take to run it on a platform that you don't have. But since the +Most of the time, you run MPI code with SMPI to compute the time it +would take to run it on a platform. But since the code is run through the \c smpirun script, you don't have any control -on the launcher code, making difficult to report the simulated time +on the launcher code, making it difficult to report the simulated time when the simulation ends. If you set the \b smpi/display_timing item to 1, \c smpirun will display this information when the simulation ends. \verbatim Simulation time: 1e3 seconds. @@ -1079,9 +1066,6 @@ silently overflow on other parts of the memory. - \c exception/cutpath: \ref options_exception_cutpath -- \c gtnets/jitter: \ref options_pls -- \c gtnets/jitter_seed: \ref options_pls - - \c host/model: \ref options_model_select - \c maxmin/precision: \ref options_model_precision @@ -1124,7 +1108,7 @@ silently overflow on other parts of the memory. - \c surf/precision: \ref options_model_precision - \c For collective operations of SMPI, please refer to Section \ref options_index_smpi_coll -- \c smpi/async_small_thres: \ref options_model_network_asyncsend +- \c smpi/async_small_thresh: \ref options_model_network_asyncsend - \c smpi/bw_factor: \ref options_model_smpi_bw_factor - \c smpi/coll_selector: \ref options_model_smpi_collectives - \c smpi/cpu_threshold: \ref options_smpi_bench @@ -1138,7 +1122,7 @@ silently overflow on other parts of the memory. - \c smpi/privatize_global_variables: \ref options_smpi_global - \c smpi/running_power: \ref options_smpi_bench - \c smpi/send_is_detached_thresh: \ref options_model_smpi_detached -- \c smpi/simulation_computation: \ref options_smpi_bench +- \c smpi/simulate_computation: \ref options_smpi_bench - \c smpi/test: \ref options_model_smpi_test - \c smpi/use_shared_malloc: \ref options_model_smpi_use_shared_malloc - \c smpi/wtime: \ref options_model_smpi_wtime