X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/34dd010877669cba8804b45bcd6a5e415f8984aa..f5622233b9834d29220974080a2cdbc51accecea:/doc/doxygen/options.doc diff --git a/doc/doxygen/options.doc b/doc/doxygen/options.doc index 34f3b8fa55..9f675d7855 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. @@ -65,7 +67,7 @@ int main(int argc, char *argv[]) { \section options_model Configuring the platform models \anchor options_storage_model -\anchor options_vm_workstation_model +\anchor options_vm_model \subsection options_model_select Selecting the platform models SimGrid comes with several network, CPU and storage models built in, and you @@ -76,9 +78,9 @@ you a short description of all possible values. Also, \c --help-models should provide information about all models for all existing resources. - \b network/model: specify the used network model - \b cpu/model: specify the used CPU model - - \b workstation/model: specify the used workstation model + - \b host/model: specify the used host model - \b storage/model: specify the used storage model (there is currently only one such model - this option is hence only useful for future releases) - - \b vm_workstation/model: specify the workstation model for virtual machines (there is currently only one such model - this option is hence only useful for future releases) + - \b vm/model: specify the model for virtual machines (there is currently only one such model - this option is hence only useful for future releases) %As of writing, the following network models are accepted. Over the time new models can be added, and some experimental models can be @@ -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,30 +120,48 @@ 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 Concerning the CPU, we have only one model for now: - \b Cas01: Simplistic CPU model (time=size/power) -The workstation concept is the aggregation of a CPU with a network +The host concept is the aggregation of a CPU with a network card. Three models exists, but actually, only 2 of them are interesting. The "compound" one is simply due to the way our internal code is organized, and can easily be ignored. So at the end, you have -two workstation models: The default one allows to aggregate an +two host models: The default one allows to aggregate an existing CPU model with an existing network model, but does not 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. - - \b default: Default workstation model. Currently, CPU:Cas01 and + - \b default: Default host model. Currently, CPU:Cas01 and network:LV08 (with cross traffic enabled) - - \b compound: Workstation model that is automatically chosen if + - \b compound: Host model that is automatically chosen if you change the network and CPU models - - \b ptask_L07: Workstation model somehow similar to Cas01+CM02 but + - \b ptask_L07: Host model somehow similar to Cas01+CM02 but allowing parallel tasks +\subsection options_generic_plugin Plugins + +SimGrid supports the use of plugins; currently, no known plugins +can be activated but there are use-cases where you may want to write +your own plugin (for instance, for logging). + +Plugins can for instance define own classes that inherit from +existing classes (for instance, a class "CpuEnergy" inherits from +"Cpu" to assess energy consumption). + +The plugin connects to the code by registering callbacks using +``surf_callback_register`` (see file ``src/surf/plugins/energy.cpp`` for details). + +\verbatim + --cfg=plugin:Energy +\endverbatim + +\note + This option is case-sensitive: Energy and energy are not the same! + \subsection options_model_optim Optimization level of the platform models The network and CPU models that are based on lmm_solve (that @@ -243,17 +263,18 @@ 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). -Note that with the default workstation model this option is activated by default. +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. @@ -296,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 @@ -327,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 @@ -348,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 @@ -371,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 @@ -531,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. @@ -552,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 @@ -745,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 @@ -773,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. @@ -1059,8 +1066,7 @@ 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 @@ -1095,6 +1101,8 @@ silently overflow on other parts of the memory. - \c network/weight_S: \ref options_model_network_coefs - \c ns3/TcpModel: \ref options_pls +- \c path: \ref options_generic_path +- \c plugin: \ref options_generic_plugin - \c surf/nthreads: \ref options_model_nthreads - \c surf/precision: \ref options_model_precision @@ -1114,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 @@ -1122,24 +1130,12 @@ silently overflow on other parts of the memory. - \c Tracing configuration options can be found in Section \ref tracing_tracing_options. - \c storage/model: \ref options_storage_model -- \c path: \ref options_generic_path -- \c plugin: \ref options_generic_plugin - \c verbose-exit: \ref options_generic_exit -- \c vm_workstation/model: \ref options_vm_workstation_model -- \c workstation/model: \ref options_model_select +- \c vm/model: \ref options_vm_model \subsection options_index_smpi_coll Index of SMPI collective algorithms options -- \c smpi/allgather: \ref options_model_smpi_coll_allgather -- \c smpi/allgatherv: \ref options_model_smpi_coll_allgatherv -- \c smpi/allreduce: \ref options_model_smpi_coll_allreduce -- \c smpi/alltoall: \ref options_model_smpi_coll_alltoall -- \c smpi/alltoallv: \ref options_model_smpi_coll_alltoallv -- \c smpi/barrier: \ref options_model_smpi_coll_barrier -- \c smpi/bcast: \ref options_model_smpi_coll_bcast -- \c smpi/gather: \ref options_model_smpi_coll_gather -- \c smpi/reduce: \ref options_model_smpi_coll_reduce -- \c smpi/reduce_scatter: \ref options_model_smpi_coll_reduce_scatter -- \c smpi/scatter: \ref options_model_smpi_coll_scatter + +TODO: All available collective algorithms will be made available via the ``smpirun --help-coll`` command. */