+This page focuses on the **performance models** that compute the duration of :ref:`every activities <S4U_main_concepts>`
+in the simulator depending on the platform characteristics and on the other activities that are currently sharing the
+resources. If you look for other kind of models (such as routing models or compute model), please refer to :ref:`the
+bottom of this page <models_other>`.
+
+Modeled resources
+*****************
+
+The main objective of SimGrid is to provide timing information for three following kind of resources: network, CPU,
+and disk.
+
+The **network models** have been improved and regularly assessed for almost 20 years. It should be possible to get
+accurate predictions once you properly :ref:`calibrate the models for your settings<models_calibration>`. As detailed
+in the next sections, SimGrid provides several network models. Two plugins can also be used to compute the network
+energy consumption: One for the :ref:`wired networks<plugin_link_energy>`, and another one for the :ref:`Wi-Fi networks
+<plugin_link_energy>`. Some users find :ref:`TCP simulated performance counter-intuitive<understanding_lv08>` at first
+in SimGrid, sometimes because of a misunderstanding of the TCP behavior in real networks.
+
+The **computing models** are less developed in SimGrid. Through the S4U interface, the user specifies the amount of
+computational work (expressed in FLOPs, for floating point operations) that each computation "consumes", and the model
+simply divides this amount by the host's FLOP rate to compute the duration of this execution. In SMPI, the user code
+is automatically timed, and the :ref:`computing speed<cfg=smpi/host-speed>` of the host machine is used to evaluate
+the corresponding amount of FLOPs. This model should be sufficient for most users, even though assuming a constant FLOP
+rate for each machine remains a crude simplification. In reality, the flops rate varies because of I/O, memory, and
+cache effects. It is somehow possible to :ref:`overcome this simplification<cfg=smpi/comp-adjustment-file>`, but the
+required calibration process is rather intricate and not documented yet (feel free to
+:ref:`contact the community<community>` on need).
+In the future, more advanced models may be added but the existing model proved good enough for all experiments done on
+distributed applications during the last two decades. The CPU energy consumption can be computed with the
+:ref:`relevant plugin<plugin_host_energy>`.
+
+The **disk models** of SimGrid are more recent than those for the network and computing resources, but they should
+still be correct for most users. `Studies have shown <https://hal.inria.fr/hal-01197128>`_ that they are sensitive
+under some conditions, and a :ref:`calibration process<howto_disk>` is provided. As usual, you probably want to
+double-check their predictions through an appropriate validation campaign.
+
+LMM-based Models
+****************
+
+SimGrid aims at the sweet spot between accuracy and simulation speed. About accuracy, our goal is to report correct
+performance trends when comparing competing designs with a minimal burden on the user, while allowing power users to
+fine tune the simulation models for predictions that are within 5% or less of the results on real machines. For
+example, we determined the `speedup achieved by the Tibidabo ARM-based cluster <http://hal.inria.fr/hal-00919507>`_
+before it was even built. About simulation speed, the tool must be fast and scalable enough to study modern IT systems
+at scale. SimGrid was for example used to simulate `a Chord ring involving millions of actors
+<https://hal.inria.fr/inria-00602216>`_ (even though that has not really been more instructive than smaller scale
+simulations for this protocol), or `a qualification run at full-scale of the Stampede supercomputer
+<https://hal.inria.fr/hal-02096571>`_.
+
+Most of our models are based on a linear max-min solver (LMM), as depicted below. The actors' activities are
+represented by actions in the simulation kernel, accounting for both the initial amount of work of the corresponding
+activity (in FLOPs for computing activities or bytes for networking and disk activities), and the currently remaining
+amount of work to process.
+
+At each simulation step, the instantaneous computing and communicating capacity of each action is computed according
+to the model. A set of constraints is used to express for example that the accumulated instantaneous consumption of a
+given resource by a set actions must remain smaller than the nominal capacity speed of that resource. In the example
+below, it is stated that the speed :math:`\varrho_1` of activity 1 plus the speed :math:`\varrho_n`
+of activity :math:`n` must remain smaller than the capacity :math:`C_A` of the corresponding host A.
+
+.. image:: img/lmm-overview.svg
+
+There are obviously many valuations of :math:`\varrho_1, \ldots{}, \varrho_n` that respect such as set of constraints.
+SimGrid usually computes the instantaneous speeds according to a Max-Min objective function, that is maximizing the
+minimum over all :math:`\varrho_i`. The coefficients associated to each variable in the inequalities are used to model
+some performance effects, such as the fact that TCP tends to favor communications with small RTTs. These coefficients
+are computed from both hard-coded values and :ref:`latency and bandwidth factors<cfg=network/latency-factor>` (more
+details on network performance modeling is given in the next section).
+
+Once the instantaneous speeds are computed, the simulation kernel determines what is the earliest terminating action
+from their respective speeds and remaining amounts of work. The simulated time is then updated along with the values
+in the LMM. As some actions have nothing left to do, the corresponding activities thus terminate, which in turn
+unblocks the corresponding actors that can further execute.
+
+Most of the SimGrid models build upon the LMM solver, that they adapt and configure for their respective usage. For CPU
+and disk activities, the LMM-based models are respectively named **Cas01** and **S19**. The existing network models are
+described in the next section.
+
+The TCP models
+**************
+
+SimGrid provides several network performance models which compute the time taken by each communication in isolation.
+**CM02** is the simplest one. It captures TCP windowing effects, but does not introduce any correction factors. This
+model should be used if you prefer understandable results over realistic ones. **LV08** (the default model) uses
+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>`.
+
+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.
+
+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
+communications are not slowed down, because there is no contention yet).
+
+In addition to these LMM-based models, you can use the :ref:`ns-3 simulator as a network model <models_ns3>`. It is much
+more detailed than the pure SimGrid models and thus slower, but it is easier to get more accurate results. Concerning
+the speed, both simulators are linear in the size of their input, but ns-3 has a much larger input in case of large
+steady communications. On the other hand, the SimGrid models must be carefully :ref:`calibrated <models_calibration>` if
+accuracy is really important to your study, while ns-3 models are less demanding with that regard.
+
+CM02
+====
+
+This is a simple model of TCP performance, where the sender stops sending packets when its TCP window is full. If the
+acknowledgment packets are returned in time to the sender, the TCP window has no impact on the performance that then is
+only limited by the link bandwidth. Otherwise, late acknowledgments will reduce the bandwidth.
+
+SimGrid models this mechanism as follows: :math:`realBW = min(physicalBW, \frac{TCP_GAMMA}{2\times latency})` The used
+bandwidth is either the physical bandwidth that is configured in the platform, or a value representing the bandwidth
+limit due to late acknowledgments. This value is the maximal TCP window size (noted TCP Gamma in SimGrid) over the
+round-trip time (i.e. twice the one-way latency). The default value of TCP Gamma is 4194304. This can be changed with
+the :ref:`network/TCP-gamma <cfg=network/TCP-gamma>` configuration item.
+
+Let's compute the time it takes to send 10 Gb of data over a 10 Gb/s link that is otherwise unused. This is always given
+by :math:`latency + 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, it obviously takes one second.
+ - If the link latency is 0.00001s, :math:`gamma/2\times lat=209,715,200,000 \approx 209Gb/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:`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!
+
+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).