+Manual calibration factors
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+SimGrid can take network irregularities such as a slow startup or changing behavior depending on the message size into account.
+The values provided by default were computed a long time ago through data fitting one the timings of either packet-level
+simulators or direct experiments on real platforms. These default values should be OK for most users, but if simulation realism
+is really important to you, you probably want to recalibrate the models (i.e., devise sensible values for your specific
+settings). This section only describes how to pass new values to the models while the calibration process involved in the
+computation of these values is described :ref:`in the relevant chapter <models_calibration>`.
+
+We found out that many networking effects can be realistically accounted for with the three following correction factors. They
+were shown to be enough to capture slow-start effects, the different transmission modes of MPI systems (eager vs. rendez-vous
+mode), or the non linear effects of wifi sharing.
+
+**Option** ``network/latency-factor`` **Default:** 1.0, but overridden by most models
+
+This option specifies a multiplier to apply to the *physical* latency (i.e., the one described in the platform) of the set of
+links involved in a communication. The factor can either be a constant to apply to any communication, or it may depend on the
+message size. The ``CM02`` model does not use any correction factor, so the latency-factor remains to 1. The ``LV08`` model sets
+it to 13.01 to model slow-start, while the ``SMPI`` model has several possible values depending on the interval in which the
+message size falls. The default SMPI setting given below specifies for example that a message smaller than 257 bytes will get a
+latency multiplier of 2.01467 while a message whose size is in [15424, 65472] will get a latency multiplier of 3.48845. The
+``wifi`` model goes further and uses a callback in the program to compute the factor that must be non-linear in this case.
+
+This multiplier is applied to the latency computed from the platform, that is the sum of all link *physical* latencies over the
+:ref:`network path <platform_routing>` used by the considered communication, to derive the *effective* end-to-end latency.