and disk activities, the LMM-based models are respectively named **Cas01** and **S19**. The existing network models are
described in the next section.
+.. _models_TCP:
+
The TCP models
**************
constant factors that are intended to capture common effects such as slow-start, the fact that TCP headers reduce the
*effective* bandwidth, or TCP's ACK messages. **SMPI** uses more advanced factors that also capture the MPI-specific
effects such as the switch between the eager vs. rendez-vous communication modes. You can :ref:`choose the
-model<options_model_select>` on command line, and these models can be :ref:`further configured<options_model>`.
+model <options_model_select>` on command line, and these models can be :ref:`further configured <options_model>`.
The LMM solver is then used as described above to compute the effect of contention on the communication time that is
-computed by the TCP model. For sake of realism, the sharing on saturated links is not necessarily a fair sharing.
-Instead, flows receive an amount of bandwidth inversely proportional to their round trip time.
+computed by the TCP model. For sake of realism, the sharing on saturated links is not necessarily a fair sharing
+(unless when ``weight-S=0``, in which case the following mechanism is disabled).
+Instead, flows receive an amount of bandwidth somehow inversely proportional to their round trip time. This is modeled
+in the LMM as a priority which depends on the :ref:`weight-S <cfg=network/weight-S>` parameter. More precisely, this
+priority is computed for each flow as :math:`\displaystyle\sum_{l\in links}\left(Lat(l)+\frac{weightS}{Bandwidth(l)}\right)`, i.e., as the sum of the
+latencies of all links traversed by the communication, plus the sum of `weight-S` over the bandwidth of each link on
+the path. Intuitively, this dependency on the bandwidth of the links somehow accounts for the protocol reactivity.
Regardless of the used TCP model, the latency is paid beforehand. It is as if the communication only starts after a
little delay corresponding to the latency. During that time, the communication has no impact on the links (the other
the :ref:`network/TCP-gamma <cfg=network/TCP-gamma>` configuration item.
If you want to disable this mechanism altogether (to model e.g. UDP or memory movements), you should set TCP-gamma
-to 0. Otherwise, the time it takes to send 10 Gb of data over a 10 Gb/s link that is otherwise unused is computed as
+to 0. Otherwise, the time it takes to send 10 Gib of data over a 10 Gib/s link that is otherwise unused is computed as
follows. This is always given by :math:`latency + \frac{size}{bandwidth}`, but the bandwidth to use may be the physical
one (10Gb/s) or the one induced by the TCP window, depending on the latency.
- If the link latency is 0, the communication obviously takes one second.
- - If the link latency is 0.00001s, :math:`\frac{gamma}{2\times lat}=209,715,200,000 \approx 209Gb/s` which is larger than the
+ - If the link latency is 0.00001s, :math:`\frac{gamma}{2\times lat}=209,715,200,000 \approx 209Gib/s` which is larger than the
physical bandwidth. So the physical bandwidth is used (you fully use the link) and the communication takes 1.00001s
- - If the link latency is 0.001s, :math:`\frac{gamma}{2\times lat}=2,097,152,000 \approx 2Gb/s`, which is smalled than the
- physical bandwidth. The communication thus fails to fully use the link, and takes 5.12s.
- - With a link latency of 0.1s, :math:`gamma/2\times lat \approx 21Mb/s`, so the communication takes 512 seconds!
+ - If the link latency is 0.001s, :math:`\frac{gamma}{2\times lat}=2,097,152,000 \approx 2Gib/s`, which is smalled than the
+ physical bandwidth. The communication thus fails to fully use the link, and takes about 4.77s.
+ - With a link latency of 0.1s, :math:`gamma/2\times lat \approx 21Mb/s`, so the communication takes about 476.84 + 0.1 seconds!
+ - More cases are tested and enforced by the test ``teshsuite/models/cm02-tcpgamma/cm02-tcpgamma.tesh``
For more details, please refer to "A Network Model for Simulation of Grid Application" by Henri Casanova and Loris
Marchal (published in 2002, thus the model name).
LV08 (default)
==============
-This model builds upon CM02 to model TCP windowing. It also introduces corrections factors for further realism. Lets
-consider the following platform:
+This model builds upon CM02 to model TCP windowing (see above). It also introduces corrections factors for further realism:
+latency-factor is 13.01, bandwidth-factor is 0.97 while weight-S is 20537. Lets consider the following platform:
.. code-block:: xml
For more details, please refer to "Accuracy study and improvement of network simulation in the SimGrid framework" by
Arnaud Legrand and Pedro Velho.
+.. _models_l07:
+
Parallel tasks (L07)
********************
Max-Min objective function requires that all variables are expressed using the same unit. This is also why in reality,
we have one LMM system per resource kind in the simulation, but the idea remains similar.
+Use the :ref:`relevant configuration <options_model_select>` to select this model in your simulation.
+
.. _models_wifi:
WiFi zones
FMI-based models
****************
-`FMI <https://fmi-standard.org/>`_ is a standard to exchange models between simulators. If you want to plug such a model
-into SimGrid, you need the `SimGrid-FMI external plugin <https://framagit.org/simgrid/simgrid-FMI>`_.
+`FMI <https://fmi-standard.org/>`_ is a standard to exchange models between simulators. If you want to plug such a model
+into SimGrid, you need the `SimGrid-FMI external plugin <https://framagit.org/simgrid/simgrid-FMI>`_.
There is a specific `documentation <https://simgrid.frama.io/simgrid-FMI/index.html>`_ available for the plugin.
-This was used to accurately study a *Smart grid* through co-simulation: `PandaPower <http://www.pandapower.org/>`_ was
-used to simulate the power grid, `ns-3 <https://nsnam.org/>`_ was used to simulate the communication network while SimGrid was
-used to simulate the IT infrastructure. Please also refer to the `relevant publication <https://hal.science/hal-03217562>`_
+This was used to accurately study a *Smart grid* through co-simulation: `PandaPower <http://www.pandapower.org/>`_ was
+used to simulate the power grid, `ns-3 <https://nsnam.org/>`_ was used to simulate the communication network while SimGrid was
+used to simulate the IT infrastructure. Please also refer to the `relevant publication <https://hal.science/hal-03217562>`_
for more details.
.. _models_other:
