Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
[DOC] Fixed even more errors.
[simgrid.git] / doc / doxygen / options.doc
index 450c710..c01adfc 100644 (file)
@@ -153,7 +153,8 @@ 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).
+``signal.connect(callback)`` (see file ``src/surf/plugins/energy.cpp`` for
+details).
 
 \verbatim
     --cfg=plugin:Energy
@@ -254,7 +255,7 @@ deployment of processes on nodes.
 
 \subsubsection options_model_network_crosstraffic Simulating cross-traffic
 
-As of SimGrid v3.7, cross-traffic effects can be taken into account in
+%As of SimGrid v3.7, cross-traffic effects can be taken into account in
 analytical simulations. It means that ongoing and incoming
 communication flows are treated independently. In addition, the LV08
 model adds 0.05 of usage on the opposite direction for each new
@@ -294,7 +295,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.
@@ -534,8 +535,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.
@@ -555,6 +556,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
@@ -747,8 +752,15 @@ being replayed/simulated. At the moment, these computation events can
 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/simulate_computation should be set to no
+application, the variable \b smpi/simulate_computation should be set to no.
+Equivalently, setting \b smpi/cpu_threshold to -1 also ignores all
+computation.
+
+\note
+    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 the chapter
+    \ref SMPI_adapting_speed.
 
 \subsection options_model_smpi_bw_factor smpi/bw_factor: Bandwidth factors
 
@@ -776,10 +788,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.
@@ -1104,7 +1116,7 @@ silently overflow on other parts of the memory.
 - \c surf/precision: \ref options_model_precision
 
 - \c <b>For collective operations of SMPI, please refer to Section \ref options_index_smpi_coll</b>
-- \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