1 /*! \page options Simgrid options and configurations
3 A number of options can be given at runtime to change the default
4 SimGrid behavior. For a complete list of all configuration options
5 accepted by the SimGrid version used in your simulator, simply pass
6 the --help configuration flag to your program. If some of the options
7 are not documented on this page, this is a bug that you should please
8 report so that we can fix it. Note that some of the options presented
9 here may not be available in your simulators, depending on the
10 @ref install_src_config "compile-time options" that you used.
12 \section options_using Passing configuration options to the simulators
14 There is several way to pass configuration options to the simulators.
15 The most common way is to use the \c --cfg command line argument. For
16 example, to set the item \c Item to the value \c Value, simply
17 type the following: \verbatim
18 my_simulator --cfg=Item:Value (other arguments)
21 Several \c `--cfg` command line arguments can naturally be used. If you
22 need to include spaces in the argument, don't forget to quote the
23 argument. You can even escape the included quotes (write \' for ' if
24 you have your argument between ').
26 Another solution is to use the \c \<config\> tag in the platform file. The
27 only restriction is that this tag must occure before the first
28 platform element (be it \c \<AS\>, \c \<cluster\>, \c \<peer\> or whatever).
29 The \c \<config\> tag takes an \c id attribute, but it is currently
30 ignored so you don't really need to pass it. The important par is that
31 within that tag, you can pass one or several \c \<prop\> tags to specify
32 the configuration to use. For example, setting \c Item to \c Value
33 can be done by adding the following to the beginning of your platform
37 <prop id="Item" value="Value"/>
41 A last solution is to pass your configuration directly using the C
42 interface. If you happen to use the MSG interface, this is very easy
43 with the MSG_config() function. If you do not use MSG, that's a bit
44 more complex, as you have to mess with the internal configuration set
45 directly as follows. Check the \ref XBT_config "relevant page" for
46 details on all the functions you can use in this context, \c
47 _sg_cfg_set being the only configuration set currently used in
51 #include <xbt/config.h>
53 extern xbt_cfg_t _sg_cfg_set;
55 int main(int argc, char *argv[]) {
58 /* Prefer MSG_config() if you use MSG!! */
59 xbt_cfg_set_parse(_sg_cfg_set,"Item:Value");
65 \section options_model Configuring the platform models
67 \subsection options_model_select Selecting the platform models
69 SimGrid comes with several network and CPU models built in, and you
70 can change the used model at runtime by changing the passed
71 configuration. The three main configuration items are given below.
72 For each of these items, passing the special \c help value gives
73 you a short description of all possible values. Also, \c --help-models
74 should provide information about all models for all existing resources.
75 - \b network/model: specify the used network model
76 - \b cpu/model: specify the used CPU model
77 - \b workstation/model: specify the used workstation model
79 As of writting, the accepted network models are the following. Over
80 the time new models can be added, and some experimental models can be
81 removed; check the values on your simulators for an uptodate
82 information. Note that the CM02 model is described in the research report
83 <a href="ftp://ftp.ens-lyon.fr/pub/LIP/Rapports/RR/RR2002/RR2002-40.ps.gz">A
84 Network Model for Simulation of Grid Application</a> while LV08 is
86 <a href="http://mescal.imag.fr/membres/arnaud.legrand/articles/simutools09.pdf">Accuracy Study and Improvement of Network Simulation in the SimGrid Framework</a>.
88 - \b LV08 (default one): Realistic network analytic model
89 (slow-start modeled by multiplying latency by 10.4, bandwidth by
90 .92; bottleneck sharing uses a payload of S=8775 for evaluating RTT)
91 - \b Constant: Simplistic network model where all communication
92 take a constant time (one second). This model provides the lowest
93 realism, but is (marginally) faster.
94 - \b SMPI: Realistic network model specifically tailored for HPC
95 settings (accurate modeling of slow start with correction factors on
96 three intervals: < 1KiB, < 64 KiB, >= 64 KiB). See also \ref
97 options_model_network_coefs "this section" for more info.
98 - \b CM02: Legacy network analytic model (Very similar to LV08, but
99 without corrective factors. The timings of small messages are thus
101 - \b Reno: Model from Steven H. Low using lagrange_solve instead of
102 lmm_solve (experts only; check the code for more info).
103 - \b Reno2: Model from Steven H. Low using lagrange_solve instead of
104 lmm_solve (experts only; check the code for more info).
105 - \b Vegas: Model from Steven H. Low using lagrange_solve instead of
106 lmm_solve (experts only; check the code for more info).
108 If you compiled SimGrid accordingly, you can use packet-level network
109 simulators as network models (see \ref pls). In that case, you have
110 two extra models, described below, and some \ref options_pls "specific
111 additional configuration flags".
112 - \b GTNets: Network pseudo-model using the GTNets simulator instead
114 - \b NS3: Network pseudo-model using the NS3 tcp model instead of an
117 Concerning the CPU, we have only one model for now:
118 - \b Cas01: Simplistic CPU model (time=size/power)
120 The workstation concept is the aggregation of a CPU with a network
121 card. Three models exists, but actually, only 2 of them are
122 interesting. The "compound" one is simply due to the way our internal
123 code is organized, and can easily be ignored. So at the end, you have
124 two workstation models: The default one allows to aggregate an
125 existing CPU model with an existing network model, but does not allow
126 parallel tasks because these beasts need some collaboration between
127 the network and CPU model. That is why, ptask_07 is used by default
129 - \b default: Default workstation model. Currently, CPU:Cas01 and
130 network:LV08 (with cross traffic enabled)
131 - \b compound: Workstation model that is automatically chosen if
132 you change the network and CPU models
133 - \b ptask_L07: Workstation model somehow similar to Cas01+CM02 but
134 allowing parallel tasks
136 \subsection options_model_optim Optimization level of the platform models
138 The network and CPU models that are based on lmm_solve (that
139 is, all our analytical models) accept specific optimization
141 - items \b network/optim and \b CPU/optim (both default to 'Lazy'):
142 - \b Lazy: Lazy action management (partial invalidation in lmm +
143 heap in action remaining).
144 - \b TI: Trace integration. Highly optimized mode when using
145 availability traces (only available for the Cas01 CPU model for
147 - \b Full: Full update of remaining and variables. Slow but may be
148 useful when debugging.
149 - items \b network/maxmin_selective_update and
150 \b cpu/maxmin_selective_update: configure whether the underlying
151 should be lazily updated or not. It should have no impact on the
152 computed timings, but should speed up the computation.
154 It is still possible to disable the \c maxmin_selective_update feature
155 because it can reveal counter-productive in very specific scenarios
156 where the interaction level is high. In particular, if all your
157 communication share a given backbone link, you should disable it:
158 without \c maxmin_selective_update, every communications are updated
159 at each step through a simple loop over them. With that feature
160 enabled, every communications will still get updated in this case
161 (because of the dependency induced by the backbone), but through a
162 complicated pattern aiming at following the actual dependencies.
164 \subsection options_model_precision Numerical precision of the platform models
166 The analytical models handle a lot of floating point values. It is
167 possible to change the epsilon used to update and compare them through
168 the \b maxmin/precision item (default value: 0.00001). Changing it
169 may speedup the simulation by discarding very small actions, at the
170 price of a reduced numerical precision.
172 \subsection options_model_nthreads Parallel threads for model updates
174 By default, Surf computes the analytical models sequentially to share their
175 resources and update their actions. It is possible to run them in parallel,
176 using the \b surf/nthreads item (default value: 1). If you use a
177 negative or null value, the amount of available cores is automatically
178 detected and used instead.
180 Depending on the workload of the models and their complexity, you may get a
181 speedup or a slowdown because of the synchronization costs of threads.
183 \subsection options_model_network Configuring the Network model
185 \subsubsection options_model_network_gamma Maximal TCP window size
187 The analytical models need to know the maximal TCP window size to take
188 the TCP congestion mechanism into account. This is set to 20000 by
189 default, but can be changed using the \b network/TCP_gamma item.
191 On linux, this value can be retrieved using the following
192 commands. Both give a set of values, and you should use the last one,
193 which is the maximal size.\verbatim
194 cat /proc/sys/net/ipv4/tcp_rmem # gives the sender window
195 cat /proc/sys/net/ipv4/tcp_wmem # gives the receiver window
198 \subsubsection options_model_network_coefs Corrective simulation factors
200 These factors allow to betterly take the slow start into account.
201 The corresponding values were computed through data fitting one the
202 timings of packet-level simulators. You should not change these values
203 unless you are really certain of what you are doing. See
204 <a href="http://mescal.imag.fr/membres/arnaud.legrand/articles/simutools09.pdf">Accuracy Study and Improvement of Network Simulation in the SimGrid Framework</a>
205 for more informations about these coeficients.
207 If you are using the SMPI model, these correction coeficients are
208 themselves corrected by constant values depending on the size of the
209 exchange. Again, only hardcore experts should bother about this fact.
211 \subsubsection options_model_network_crosstraffic Simulating cross-traffic
213 As of SimGrid v3.7, cross-traffic effects can be taken into account in
214 analytical simulations. It means that ongoing and incoming
215 communication flows are treated independently. In addition, the LV08
216 model adds 0.05 of usage on the opposite direction for each new
217 created flow. This can be useful to simulate some important TCP
218 phenomena such as ack compression.
220 For that to work, your platform must have two links for each
221 pair of interconnected hosts. An example of usable platform is
222 available in <tt>examples/msg/gtnets/crosstraffic-p.xml</tt>.
224 This is activated through the \b network/crosstraffic item, that
225 can be set to 0 (disable this feature) or 1 (enable it).
227 Note that with the default workstation model this option is activated by default.
229 \subsubsection options_model_network_coord Coordinated-based network models
231 When you want to use network coordinates, as it happens when you use
232 an \<AS\> in your platform file with \c Vivaldi as a routing, you must
233 set the \b network/coordinates to \c yes so that all mandatory
234 initialization are done in the simulator.
236 \subsubsection options_model_network_sendergap Simulating sender gap
238 (this configuration item is experimental and may change or disapear)
240 It is possible to specify a timing gap between consecutive emission on
241 the same network card through the \b network/sender_gap item. This
242 is still under investigation as of writting, and the default value is
243 to wait 10 microseconds (1e-5 seconds) between emissions.
245 \subsubsection options_model_network_asyncsend Simulating asyncronous send
247 (this configuration item is experimental and may change or disapear)
249 It is possible to specify that messages below a certain size will be sent
250 as soon as the call to MPI_Send is issued, without waiting for the
251 correspondant receive. This threshold can be configured through the
252 \b smpi/async_small_thres item. The default value is 0. This behavior can also be
253 manually set for MSG mailboxes, by setting the receiving mode of the mailbox
254 with a call to \ref MSG_mailbox_set_async . For MSG, all messages sent to this
255 mailbox will have this behavior, so consider using two mailboxes if needed.
257 This value needs to be smaller than or equals to the threshold set at
258 \ref options_model_smpi_detached , because asynchronous messages are
259 meant to be detached as well.
261 \subsubsection options_pls Configuring packet-level pseudo-models
263 When using the packet-level pseudo-models, several specific
264 configuration flags are provided to configure the associated tools.
265 There is by far not enough such SimGrid flags to cover every aspects
266 of the associated tools, since we only added the items that we
267 needed ourselves. Feel free to request more items (or even better:
268 provide patches adding more items).
270 When using NS3, the only existing item is \b ns3/TcpModel,
271 corresponding to the ns3::TcpL4Protocol::SocketType configuration item
272 in NS3. The only valid values (enforced on the SimGrid side) are
273 'NewReno' or 'Reno' or 'Tahoe'.
275 When using GTNeTS, two items exist:
276 - \b gtnets/jitter, that is a double value to oscillate
277 the link latency, uniformly in random interval
278 [-latency*gtnets_jitter,latency*gtnets_jitter). It defaults to 0.
279 - \b gtnets/jitter_seed, the positive seed used to reproduce jitted
280 results. Its value must be in [1,1e8] and defaults to 10.
282 \section options_modelchecking Configuring the Model-Checking
284 To enable the experimental SimGrid model-checking support the program should
285 be executed with the command line argument
289 Safety properties are expressed as assertions using the function
291 void MC_assert(int prop);
294 \subsection options_modelchecking_liveness Specifying a liveness property
296 If you want to specify liveness properties (beware, that's
297 experimental), you have to pass them on the command line, specifying
298 the name of the file containing the property, as formated by the
302 --cfg=model-check/property:<filename>
305 Of course, specifying a liveness property enables the model-checking
306 so that you don't have to give <tt>--cfg=model-check:1</tt> in
309 \subsection options_modelchecking_steps Going for stateful verification
311 By default, the system is backtracked to its initial state to explore
312 another path instead of backtracking to the exact step before the fork
313 that we want to explore (this is called stateless verification). This
314 is done this way because saving intermediate states can rapidly
315 exhaust the available memory. If you want, you can change the value of
316 the <tt>model-check/checkpoint</tt> variable. For example, the
317 following configuration will ask to take a checkpoint every step.
318 Beware, this will certainly explode your memory. Larger values are
319 probably better, make sure to experiment a bit to find the right
320 setting for your specific system.
323 --cfg=model-check/checkpoint:1
326 Of course, specifying this option enables the model-checking so that
327 you don't have to give <tt>--cfg=model-check:1</tt> in addition.
329 \subsection options_modelchecking_reduction Specifying the kind of reduction
331 The main issue when using the model-checking is the state space
332 explosion. To counter that problem, several exploration reduction
333 techniques can be used. There is unfortunately no silver bullet here,
334 and the most efficient reduction techniques cannot be applied to any
335 properties. In particular, the DPOR method cannot be applied on
336 liveness properties since it may break some cycles in the exploration
337 that are important to the property validity.
340 --cfg=model-check/reduction:<technique>
343 For now, this configuration variable can take 2 values:
344 * none: Do not apply any kind of reduction (mandatory for now for
346 * dpor: Apply Dynamic Partial Ordering Reduction. Only valid if you
347 verify local safety properties.
349 Of course, specifying a reduction technique enables the model-checking
350 so that you don't have to give <tt>--cfg=model-check:1</tt> in
353 \section options_virt Configuring the User Process Virtualization
355 \subsection options_virt_factory Selecting the virtualization factory
357 In SimGrid, the user code is virtualized in a specific mecanism
358 allowing the simulation kernel to control its execution: when a user
359 process requires a blocking action (such as sending a message), it is
360 interrupted, and only gets released when the simulated clock reaches
361 the point where the blocking operation is done.
363 In SimGrid, the containers in which user processes are virtualized are
364 called contexts. Several context factory are provided, and you can
365 select the one you want to use with the \b contexts/factory
366 configuration item. Some of the following may not exist on your
367 machine because of portability issues. In any case, the default one
368 should be the most effcient one (please report bugs if the
369 auto-detection fails for you). They are sorted here from the slowest
371 - \b thread: very slow factory using full featured threads (either
372 pthreads or windows native threads)
373 - \b ucontext: fast factory using System V contexts (or a portability
374 layer of our own on top of Windows fibers)
375 - \b raw: amazingly fast factory using a context switching mecanism
376 of our own, directly implemented in assembly (only available for x86
377 and amd64 platforms for now)
379 The only reason to change this setting is when the debugging tools get
380 fooled by the optimized context factories. Threads are the most
381 debugging-friendly contextes.
383 \subsection options_virt_stacksize Adapting the used stack size
385 Each virtualized used process is executed using a specific system
386 stack. The size of this stack has a huge impact on the simulation
387 scalability, but its default value is rather large. This is because
388 the error messages that you get when the stack size is too small are
389 rather disturbing: this leads to stack overflow (overwriting other
390 stacks), leading to segfaults with corrupted stack traces.
392 If you want to push the scalability limits of your code, you really
393 want to reduce the \b contexts/stack_size item. Its default value
394 is 128 (in KiB), while our Chord simulation works with stacks as small
395 as 16 KiB, for example. For the thread factory, the default value
396 is the one of the system, if it is too large/small, it has to be set
399 \subsection options_virt_parallel Running user code in parallel
401 Parallel execution of the user code is only considered stable in
402 SimGrid v3.7 and higher. It is described in
403 <a href="http://hal.inria.fr/inria-00602216/">INRIA RR-7653</a>.
405 If you are using the \c ucontext or \c raw context factories, you can
406 request to execute the user code in parallel. Several threads are
407 launched, each of them handling as much user contexts at each run. To
408 actiave this, set the \b contexts/nthreads item to the amount of
409 cores that you have in your computer (or lower than 1 to have
410 the amount of cores auto-detected).
412 Even if you asked several worker threads using the previous option,
413 you can request to start the parallel execution (and pay the
414 associated synchronization costs) only if the potential parallelism is
415 large enough. For that, set the \b contexts/parallel_threshold
416 item to the minimal amount of user contexts needed to start the
417 parallel execution. In any given simulation round, if that amount is
418 not reached, the contexts will be run sequentially directly by the
419 main thread (thus saving the synchronization costs). Note that this
420 option is mainly useful when the grain of the user code is very fine,
421 because our synchronization is now very efficient.
423 When parallel execution is activated, you can choose the
424 synchronization schema used with the \b contexts/synchro item,
425 which value is either:
426 - \b futex: ultra optimized synchronisation schema, based on futexes
427 (fast user-mode mutexes), and thus only available on Linux systems.
428 This is the default mode when available.
429 - \b posix: slow but portable synchronisation using only POSIX
431 - \b busy_wait: not really a synchronisation: the worker threads
432 constantly request new contexts to execute. It should be the most
433 efficient synchronisation schema, but it loads all the cores of your
434 machine for no good reason. You probably prefer the other less
437 \section options_tracing Configuring the tracing subsystem
439 The \ref tracing "tracing subsystem" can be configured in several
440 different ways depending on the nature of the simulator (MSG, SimDag,
441 SMPI) and the kind of traces that need to be obtained. See the \ref
442 tracing_tracing_options "Tracing Configuration Options subsection" to
443 get a detailed description of each configuration option.
445 We detail here a simple way to get the traces working for you, even if
446 you never used the tracing API.
449 - Any SimGrid-based simulator (MSG, SimDag, SMPI, ...) and raw traces:
451 --cfg=tracing:yes --cfg=tracing/uncategorized:yes --cfg=triva/uncategorized:uncat.plist
453 The first parameter activates the tracing subsystem, the second
454 tells it to trace host and link utilization (without any
455 categorization) and the third creates a graph configuration file
456 to configure Triva when analysing the resulting trace file.
458 - MSG or SimDag-based simulator and categorized traces (you need to declare categories and classify your tasks according to them)
460 --cfg=tracing:yes --cfg=tracing/categorized:yes --cfg=triva/categorized:cat.plist
462 The first parameter activates the tracing subsystem, the second
463 tells it to trace host and link categorized utilization and the
464 third creates a graph configuration file to configure Triva when
465 analysing the resulting trace file.
467 - SMPI simulator and traces for a space/time view:
471 The <i>-trace</i> parameter for the smpirun script runs the
472 simulation with --cfg=tracing:yes and --cfg=tracing/smpi:yes. Check the
473 smpirun's <i>-help</i> parameter for additional tracing options.
475 Sometimes you might want to put additional information on the trace to
476 correctly identify them later, or to provide data that can be used to
477 reproduce an experiment. You have two ways to do that:
479 - Add a string on top of the trace file as comment:
481 --cfg=tracing/comment:my_simulation_identifier
484 - Add the contents of a textual file on top of the trace file as comment:
486 --cfg=tracing/comment_file:my_file_with_additional_information.txt
489 Please, use these two parameters (for comments) to make reproducible
490 simulations. For additional details about this and all tracing
491 options, check See the \ref tracing_tracing_options.
493 \section options_smpi Configuring SMPI
495 The SMPI interface provides several specific configuration items.
496 These are uneasy to see since the code is usually launched through the
497 \c smiprun script directly.
499 \subsection options_smpi_bench Automatic benchmarking of SMPI code
501 In SMPI, the sequential code is automatically benchmarked, and these
502 computations are automatically reported to the simulator. That is to
503 say that if you have a large computation between a \c MPI_Recv() and a
504 \c MPI_Send(), SMPI will automatically benchmark the duration of this
505 code, and create an execution task within the simulator to take this
506 into account. For that, the actual duration is measured on the host
507 machine and then scaled to the power of the corresponding simulated
508 machine. The variable \b smpi/running_power allows to specify the
509 computational power of the host machine (in flop/s) to use when
510 scaling the execution times. It defaults to 20000, but you really want
511 to update it to get accurate simulation results.
513 When the code is constituted of numerous consecutive MPI calls, the
514 previous mechanism feeds the simulation kernel with numerous tiny
515 computations. The \b smpi/cpu_threshold item becomes handy when this
516 impacts badly the simulation performance. It specify a threshold (in
517 second) under which the execution chunks are not reported to the
518 simulation kernel (default value: 1e-6). Please note that in some
519 circonstances, this optimization can hinder the simulation accuracy.
521 \subsection options_smpi_timing Reporting simulation time
523 Most of the time, you run MPI code through SMPI to compute the time it
524 would take to run it on a platform that you don't have. But since the
525 code is run through the \c smpirun script, you don't have any control
526 on the launcher code, making difficult to report the simulated time
527 when the simulation ends. If you set the \b smpi/display_timing item
528 to 1, \c smpirun will display this information when the simulation ends. \verbatim
529 Simulation time: 1e3 seconds.
532 \subsection options_model_smpi_detached Simulating MPI detached send
534 (this configuration item is experimental and may change or disapear)
536 This threshold specifies the size in bytes under which the send will return
537 immediately. This is different from the threshold detailed in \ref options_model_network_asyncsend
538 because the message is not effectively sent when the send is posted. SMPI still waits for the
539 correspondant receive to be posted to perform the communication operation. This threshold can be set
540 by changing the \b smpi/send_is_detached item. The default value is 65536.
542 \subsection options_model_smpi_collectives Simulating MPI collective algorithms
544 SMPI implements more than 100 different algorithms for MPI collective communication, to accurately
545 simulate the behavior of most of the existing MPI libraries. The \b smpi/coll_selector item can be used
546 to use the decision logic of either OpenMPI or MPICH libraries (values: ompi or mpich, by default SMPI
547 uses naive version of collective operations). Each collective operation can be manually selected with a
548 \b smpi/collective_name:algo_name. Available algorithms are listed in \ref SMPI_collective_algorithms .
550 \section options_generic Configuring other aspects of SimGrid
552 \subsection options_generic_path XML file inclusion path
554 It is possible to specify a list of directories to search into for the
555 \<include\> tag in XML files by using the \b path configuration
556 item. To add several directory to the path, set the configuration
557 item several times, as in \verbatim
558 --cfg=path:toto --cfg=path:tutu
561 \subsection options_generic_exit Behavior on Ctrl-C
563 By default, when Ctrl-C is pressed, the status of all existing
564 simulated processes is displayed. This is very useful to debug your
565 code, but it can reveal troublesome in some cases (such as when the
566 amount of processes becomes really big). This behavior is disabled
567 when \b verbose-exit is set to 0 (it is to 1 by default).
570 \section options_log Logging Configuration
572 It can be done by using XBT. Go to \ref XBT_log for more details.
575 \section options_index Index of all existing configuration items
577 - \c contexts/factory: \ref options_virt_factory
578 - \c contexts/nthreads: \ref options_virt_parallel
579 - \c contexts/parallel_threshold: \ref options_virt_parallel
580 - \c contexts/stack_size: \ref options_virt_stacksize
581 - \c contexts/synchro: \ref options_virt_parallel
583 - \c cpu/maxmin_selective_update: \ref options_model_optim
584 - \c cpu/model: \ref options_model_select
585 - \c cpu/optim: \ref options_model_optim
587 - \c gtnets/jitter: \ref options_pls
588 - \c gtnets/jitter_seed: \ref options_pls
590 - \c maxmin/precision: \ref options_model_precision
592 - \c model-check: \ref options_modelchecking
593 - \c model-check/property: \ref options_modelchecking_liveness
594 - \c model-check/checkpoint: \ref options_modelchecking_steps
595 - \c model-check/reduce: \ref options_modelchecking_reduction
597 - \c network/bandwidth_factor: \ref options_model_network_coefs
598 - \c network/coordinates: \ref options_model_network_coord
599 - \c network/crosstraffic: \ref options_model_network_crosstraffic
600 - \c network/latency_factor: \ref options_model_network_coefs
601 - \c network/maxmin_selective_update: \ref options_model_optim
602 - \c network/model: \ref options_model_select
603 - \c network/optim: \ref options_model_optim
604 - \c network/sender_gap: \ref options_model_network_sendergap
605 - \c network/TCP_gamma: \ref options_model_network_gamma
606 - \c network/weight_S: \ref options_model_network_coefs
608 - \c ns3/TcpModel: \ref options_pls
610 - \c surf/nthreads: \ref options_model_nthreads
612 - \c smpi/running_power: \ref options_smpi_bench
613 - \c smpi/display_timing: \ref options_smpi_timing
614 - \c smpi/cpu_threshold: \ref options_smpi_bench
615 - \c smpi/async_small_thres: \ref options_model_network_asyncsend
616 - \c smpi/send_is_detached: \ref options_model_smpi_detached
617 - \c smpi/coll_selector: \ref options_model_smpi_collectives
619 - \c path: \ref options_generic_path
620 - \c verbose-exit: \ref options_generic_exit
622 - \c workstation/model: \ref options_model_select