+A last solution is to pass your configuration directly using the C
+interface. Unfortunately, this path is not really easy to use right
+now, and you mess directly with surf internal variables as follows. Check the
+\ref XBT_config "relevant page" for details on all the functions you
+can use in this context, \c _surf_cfg_set being the only configuration set
+currently used in SimGrid. \code
+#include <xbt/config.h>
+
+extern xbt_cfg_t _surf_cfg_set;
+
+int main(int argc, char *argv[]) {
+ MSG_global_init(&argc, argv);
+
+ xbt_cfg_set_parse(_surf_cfg_set,"Item:Value");
+
+ // Rest of your code
+}
+\endcode
+
+\section options_model Configuring the platform models
+
+\subsection options_model_select Selecting the platform models
+
+SimGrid comes with several network and CPU models built in, and you
+can change the used model at runtime by changing the passed
+configuration. The three main configuration items are given below.
+For each of these items, passing the special \c help value gives
+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
+
+As of writting, the accepted network models are the following. Over
+the time new models can be added, and some experimental models can be
+removed; check the values on your simulators for an uptodate
+information. Note that the CM02 model is described in the research report
+<a href="ftp://ftp.ens-lyon.fr/pub/LIP/Rapports/RR/RR2002/RR2002-40.ps.gz">A
+Network Model for Simulation of Grid Application</a> while LV08 is
+described in
+<a href="http://mescal.imag.fr/membres/arnaud.legrand/articles/simutools09.pdf">Accuracy Study and Improvement of Network Simulation in the SimGrid Framework</a>.
+
+ - \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
+ 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
+ settings (accurate modeling of slow start with correction factors on
+ three intervals: < 1KiB, < 64 KiB, >= 64 KiB). See also \ref
+ options_model_network_coefs "this section" for more info.
+ - \b CM02: Legacy network analytic model (Very similar to LV08, but
+ without corrective factors. The timings of small messages are thus
+ poorly modeled)
+ - \b Reno: Model from Steven H. Low using lagrange_solve instead of
+ lmm_solve (experts only; check the code for more info).
+ - \b Reno2: Model from Steven H. Low using lagrange_solve instead of
+ lmm_solve (experts only; check the code for more info).
+ - \b Vegas: Model from Steven H. Low using lagrange_solve instead of
+ lmm_solve (experts only; check the code for more info).
+
+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
+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
+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
+ network:LV08 (with cross traffic enabled)
+ - \b compound: Workstation model that is automatically chosen if
+ you change the network and CPU models
+ - \b ptask_L07: Workstation model somehow similar to Cas01+CM02 but
+ allowing parallel tasks
+
+\subsection options_model_optim Optimization level of the platform models
+
+The network and CPU models that are based on lmm_solve (that
+is, all our analytical models) accept specific optimization
+configurations.
+ - items \b network/optim and \b CPU/optim (both default to 'Lazy'):
+ - \b Lazy: Lazy action management (partial invalidation in lmm +
+ heap in action remaining).
+ - \b TI: Trace integration. Highly optimized mode when using
+ availability traces (only available for the Cas01 CPU model for
+ now).
+ - \b Full: Full update of remaining and variables. Slow but may be
+ useful when debugging.
+ - items \b network/maxmin_selective_update and
+ \b cpu/maxmin_selective_update: configure whether the underlying
+ should be lazily updated or not. It should have no impact on the
+ computed timings, but should speed up the computation.
+
+It is still possible to disable the \c maxmin_selective_update feature
+because it can reveal counter-productive in very specific scenarios
+where the interaction level is high. In particular, if all your
+communication share a given backbone link, you should disable it:
+without \c maxmin_selective_update, every communications are updated
+at each step through a simple loop over them. With that feature
+enabled, every communications will still get updated in this case
+(because of the dependency induced by the backbone), but through a
+complicated pattern aiming at following the actual dependencies.
+
+\subsection options_model_precision Numerical precision of the platform models
+
+The analytical models handle a lot of floating point values. It is
+possible to change the epsilon used to update and compare them through
+the \b maxmin/precision item (default value: 1e-9). Changing it
+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
+
+The analytical models need to know the maximal TCP window size to take
+the TCP congestion mechanism into account. This is set to 20000 by
+default, but can be changed using the \b network/TCP_gamma item.
+
+On linux, this value can be retrieved using the following
+commands. Both give a set of values, and you should use the last one,
+which is the maximal size.\verbatim
+cat /proc/sys/net/ipv4/tcp_rmem # gives the sender window
+cat /proc/sys/net/ipv4/tcp_wmem # gives the receiver window