3 <object id="TOC" data="graphical-toc.svg" type="image/svg+xml"></object>
5 window.onload=function() { // Wait for the SVG to be loaded before changing it
6 var elem=document.querySelector("#TOC").contentDocument.getElementById("ModelBox")
7 elem.style="opacity:0.93999999;fill:#ff0000;fill-opacity:0.1;stroke:#000000;stroke-width:0.35277778;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1";
18 This page focuses on the **performance models** that compute the duration of :ref:`every activities <S4U_main_concepts>`
19 in the simulator depending on the platform characteristics and on the other activities that are currently sharing the
20 resources. If you look for other kind of models (such as routing models or compute model), please refer to :ref:`the
21 bottom of this page <models_other>`.
26 The main objective of SimGrid is to provide timing information for three following kind of resources: network, CPU,
29 The **network models** have been improved and regularly assessed for almost 20 years. It should be possible to get
30 accurate predictions once you properly :ref:`calibrate the models for your settings<models_calibration>`. As detailed
31 in the next sections, SimGrid provides several network models. Two plugins can also be used to compute the network
32 energy consumption: One for the :ref:`wired networks<plugin_link_energy>`, and another one for the :ref:`Wi-Fi networks
33 <plugin_link_energy>`. Some users find :ref:`TCP simulated performance counter-intuitive<understanding_lv08>` at first
34 in SimGrid, sometimes because of a misunderstanding of the TCP behavior in real networks.
36 The **computing models** are less developed in SimGrid. Through the S4U interface, the user specifies the amount of
37 computational work (expressed in FLOPs, for floating point operations) that each computation "consumes", and the model
38 simply divides this amount by the host's FLOP rate to compute the duration of this execution. In SMPI, the user code
39 is automatically timed, and the :ref:`computing speed<cfg=smpi/host-speed>` of the host machine is used to evaluate
40 the corresponding amount of FLOPs. This model should be sufficient for most users, even though assuming a constant FLOP
41 rate for each machine remains a crude simplification. In reality, the flops rate varies because of I/O, memory, and
42 cache effects. It is somehow possible to :ref:`overcome this simplification<cfg=smpi/comp-adjustment-file>`, but the
43 required calibration process is rather intricate and not documented yet (feel free to
44 :ref:`contact the community<community>` on need).
45 In the future, more advanced models may be added but the existing model proved good enough for all experiments done on
46 distributed applications during the last two decades. The CPU energy consumption can be computed with the
47 :ref:`relevant plugin<plugin_host_energy>`.
49 The **disk models** of SimGrid are more recent than those for the network and computing resources, but they should
50 still be correct for most users. `Studies have shown <https://hal.inria.fr/hal-01197128>`_ that they are sensitive
51 under some conditions, and a :ref:`calibration process<howto_disk>` is provided. As usual, you probably want to
52 double-check their predictions through an appropriate validation campaign.
57 SimGrid aims at the sweet spot between accuracy and simulation speed. About accuracy, our goal is to report correct
58 performance trends when comparing competing designs with a minimal burden on the user, while allowing power users to
59 fine tune the simulation models for predictions that are within 5% or less of the results on real machines. For
60 example, we determined the `speedup achieved by the Tibidabo ARM-based cluster <http://hal.inria.fr/hal-00919507>`_
61 before it was even built. About simulation speed, the tool must be fast and scalable enough to study modern IT systems
62 at scale. SimGrid was for example used to simulate `a Chord ring involving millions of actors
63 <https://hal.inria.fr/inria-00602216>`_ (even though that has not really been more instructive than smaller scale
64 simulations for this protocol), or `a qualification run at full-scale of the Stampede supercomputer
65 <https://hal.inria.fr/hal-02096571>`_.
67 Most of our models are based on a linear max-min solver (LMM), as depicted below. The actors' activities are
68 represented by actions in the simulation kernel, accounting for both the initial amount of work of the corresponding
69 activity (in FLOPs for computing activities or bytes for networking and disk activities), and the currently remaining
70 amount of work to process.
72 At each simulation step, the instantaneous computing and communicating capacity of each action is computed according
73 to the model. A set of constraints is used to express for example that the accumulated instantaneous consumption of a
74 given resource by a set actions must remain smaller than the nominal capacity speed of that resource. In the example
75 below, it is stated that the speed :math:`\varrho_1` of activity 1 plus the speed :math:`\varrho_n`
76 of activity :math:`n` must remain smaller than the capacity :math:`C_A` of the corresponding host A.
78 .. image:: img/lmm-overview.svg
80 There are obviously many valuations of :math:`\varrho_1, \ldots{}, \varrho_n` that respect such as set of constraints.
81 SimGrid usually computes the instantaneous speeds according to a Max-Min objective function, that is maximizing the
82 minimum over all :math:`\varrho_i`. The coefficients associated to each variable in the inequalities are used to model
83 some performance effects, such as the fact that TCP tends to favor communications with small RTTs. These coefficients
84 are computed from both hard-coded values and :ref:`latency and bandwidth factors<cfg=network/latency-factor>` (more
85 details on network performance modeling is given in the next section).
87 Once the instantaneous speeds are computed, the simulation kernel determines what is the earliest terminating action
88 from their respective speeds and remaining amounts of work. The simulated time is then updated along with the values
89 in the LMM. As some actions have nothing left to do, the corresponding activities thus terminate, which in turn
90 unblocks the corresponding actors that can further execute.
92 Most of the SimGrid models build upon the LMM solver, that they adapt and configure for their respective usage. For CPU
93 and disk activities, the LMM-based models are respectively named **Cas01** and **S19**. The existing network models are
94 described in the next section.
101 SimGrid provides several network performance models which compute the time taken by each communication in isolation.
102 **CM02** is the simplest one. It captures TCP windowing effects, but does not introduce any correction factors. This
103 model should be used if you prefer understandable results over realistic ones. **LV08** (the default model) uses
104 constant factors that are intended to capture common effects such as slow-start, the fact that TCP headers reduce the
105 *effective* bandwidth, or TCP's ACK messages. **SMPI** uses more advanced factors that also capture the MPI-specific
106 effects such as the switch between the eager vs. rendez-vous communication modes. You can :ref:`choose the
107 model <options_model_select>` on command line, and these models can be :ref:`further configured <options_model>`.
109 The LMM solver is then used as described above to compute the effect of contention on the communication time that is
110 computed by the TCP model. For sake of realism, the sharing on saturated links is not necessarily a fair sharing
111 (unless when ``weight-S=0``, in which case the following mechanism is disabled).
112 Instead, flows receive an amount of bandwidth somehow inversely proportional to their round trip time. This is modeled
113 in the LMM as a priority which depends on the :ref:`weight-S <cfg=network/weight-S>` parameter. More precisely, this
114 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
115 latencies of all links traversed by the communication, plus the sum of `weight-S` over the bandwidth of each link on
116 the path. Intuitively, this dependency on the bandwidth of the links somehow accounts for the protocol reactivity.
118 Regardless of the used TCP model, the latency is paid beforehand. It is as if the communication only starts after a
119 little delay corresponding to the latency. During that time, the communication has no impact on the links (the other
120 communications are not slowed down, because there is no contention yet).
122 In addition to these LMM-based models, you can use the :ref:`ns-3 simulator as a network model <models_ns3>`. It is much
123 more detailed than the pure SimGrid models and thus slower, but it is easier to get more accurate results. Concerning
124 the speed, both simulators are linear in the size of their input, but ns-3 has a much larger input in case of large
125 steady communications. On the other hand, the SimGrid models must be carefully :ref:`calibrated <models_calibration>` if
126 accuracy is really important to your study, while ns-3 models are less demanding with that regard.
128 .. _understanding_cm02:
133 This is a simple model of TCP performance, where the sender stops sending packets when its TCP window is full. If the
134 acknowledgment packets are returned in time to the sender, the TCP window has no impact on the performance that then is
135 only limited by the link bandwidth. Otherwise, late acknowledgments will reduce the bandwidth.
137 SimGrid models this mechanism as follows: :math:`real\_BW = min(physical\_BW, \frac{TCP\_GAMMA}{2\times latency})` The used
138 bandwidth is either the physical bandwidth that is configured in the platform, or a value representing the bandwidth
139 limit due to late acknowledgments. This value is the maximal TCP window size (noted TCP Gamma in SimGrid) over the
140 round-trip time (i.e. twice the one-way latency). The default value of TCP Gamma is 4194304. This can be changed with
141 the :ref:`network/TCP-gamma <cfg=network/TCP-gamma>` configuration item.
143 If you want to disable this mechanism altogether (to model e.g. UDP or memory movements), you should set TCP-gamma
144 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
145 follows. This is always given by :math:`latency + \frac{size}{bandwidth}`, but the bandwidth to use may be the physical
146 one (10Gb/s) or the one induced by the TCP window, depending on the latency.
148 - If the link latency is 0, the communication obviously takes one second.
149 - 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
150 physical bandwidth. So the physical bandwidth is used (you fully use the link) and the communication takes 1.00001s
151 - 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
152 physical bandwidth. The communication thus fails to fully use the link, and takes about 4.77s.
153 - 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!
154 - More cases are tested and enforced by the test ``teshsuite/models/cm02-tcpgamma/cm02-tcpgamma.tesh``
156 For more details, please refer to "A Network Model for Simulation of Grid Application" by Henri Casanova and Loris
157 Marchal (published in 2002, thus the model name).
159 .. _understanding_lv08:
164 This model builds upon CM02 to model TCP windowing (see above). It also introduces corrections factors for further realism:
165 latency-factor is 13.01, bandwidth-factor is 0.97 while weight-S is 20537. Lets consider the following platform:
169 <host id="A" speed="1Gf" />
170 <host id="B" speed="1Gf" />
172 <link id="link1" latency="10ms" bandwidth="1Mbps" />
174 <route src="A" dst="B">
175 <link_ctn id="link1" />
178 If host `A` sends ``100kB`` (a hundred kilobytes) to host `B`, one can expect that this communication would take `0.81`
179 seconds to complete according to a simple latency-plus-size-divided-by-bandwidth model (0.01 + 8e5/1e6 = 0.81) since the
180 latency is small enough to ensure that the physical bandwidth is used (see the discussion on CM02 above). However, the
181 LV08 model is more complex to account for three phenomena that directly impact the simulation time:
183 - The size of a message at the application level (i.e., 100kB in this example) is not the size that is actually
184 transferred over the network. To mimic the fact that TCP and IP headers are added to each packet of the original
185 payload, the TCP model of SimGrid empirically considers that `only 97% of the nominal bandwidth` are available. In
186 other words, the size of your message is increased by a few percents, whatever this size be.
188 - In the real world, the TCP protocol is not able to fully exploit the bandwidth of a link from the emission of the
189 first packet. To reflect this `slow start` phenomenon, the latency declared in the platform file is multiplied by
190 `a factor of 13.01`. Here again, this is an empirically determined value that may not correspond to every TCP
191 implementations on every networks. It can be tuned when more realistic simulated times for the transfer of short
192 messages are needed though.
194 - When data is transferred from A to B, some TCP ACK messages travel in the opposite direction. To reflect the impact
195 of this `cross-traffic`, SimGrid simulates a flow from B to A that represents an additional bandwidth consumption
196 of `0.05%`. The route from B to A is implicitly declared in the platform file and uses the same link `link1` as if
197 the two hosts were connected through a communication bus. The bandwidth share allocated to a data transfer from A
198 to B is then the available bandwidth of `link1` (i.e., 97% of the nominal bandwidth of 1Mb/s) divided by 1.05
199 (i.e., the total consumption). This feature, activated by default, can be disabled by adding the
200 ``--cfg=network/crosstraffic:0`` flag to the command line.
202 As a consequence, the time to transfer 100kB from A to B as simulated by the default TCP model of SimGrid is not 0.81
205 .. code-block:: python
207 0.01 * 13.01 + 800000 / ((0.97 * 1e6) / 1.05) = 0.996079 seconds.
209 For more details, please refer to "Accuracy study and improvement of network simulation in the SimGrid framework" by
210 Arnaud Legrand and Pedro Velho.
217 This model is rather distinct from the other LMM models because it uses another objective function called *bottleneck*.
218 This is because this model is intended to be used for parallel tasks that are actions mixing flops and bytes while the
219 Max-Min objective function requires that all variables are expressed using the same unit. This is also why in reality,
220 we have one LMM system per resource kind in the simulation, but the idea remains similar.
222 Use the :ref:`relevant configuration <options_model_select>` to select this model in your simulation.
229 In SimGrid, WiFi networks are modeled with WiFi zones, where a zone contains the access point of the WiFi network and
230 the hosts connected to it (called `stations` in the WiFi world). The network inside a WiFi zone is modeled by declaring
231 a single regular link with a specific attribute. This link is then added to the routes to and from the stations within
232 this WiFi zone. The main difference of WiFi networks is that their performance is not determined by some link bandwidth
233 and latency but by both the access point WiFi characteristics and the distance between that access point and a given
236 Such WiFi zones can be used with the LMM-based model or ns-3, and are supposed to behave similarly in both cases.
238 Declaring a WiFi zone
239 =====================
241 To declare a new WiFi network, simply declare a network zone with the ``WIFI`` routing attribute.
245 <zone id="SSID_1" routing="WIFI">
247 Inside this zone you must declare which host or router will be the access point of the WiFi network.
251 <prop id="access_point" value="alice"/>
253 Then simply declare the stations (hosts) and routers inside the WiFi network. Remember that one must have the same name
254 as the "access point" property.
258 <router id="alice" speed="1Gf"/>
259 <host id="STA0-0" speed="1Gf"/>
260 <host id="STA0-1" speed="1Gf"/>
262 Finally, close the WiFi zone.
268 The WiFi zone may be connected to another zone using a traditional link and a zoneRoute. Note that the connection between two
269 zones is always wired.
273 <link id="wireline" bandwidth="100Mbps" latency="2ms" sharing_policy="SHARED"/>
275 <zoneRoute src="SSID_1" dst="SSID_2" gw_src="alice" gw_dst="bob">
276 <link_ctn id="wireline"/>
279 WiFi network performance
280 ========================
282 The performance of a wifi network is controlled by the three following properties:
284 * ``mcs`` (`Modulation and Coding Scheme <https://en.wikipedia.org/wiki/Link_adaptation>`_)
285 is a property of the WiFi zone. Roughly speaking, it defines the speed at which the access point is exchanging data
286 with all the stations. It depends on the access point's model and configuration. Possible values for the MCS can be
287 found on Wikipedia for example.
288 |br| By default, ``mcs=3``.
289 * ``nss`` (Number of Spatial Streams, or `number of antennas <https://en.wikipedia.org/wiki/IEEE_802.11n-2009#Number_of_antennas>`_) is another property of the WiFi zone. It defines the amount of simultaneous data streams that the access
290 point can sustain. Not all values of MCS and NSS are valid nor compatible (cf. `802.11n standard <https://en.wikipedia.org/wiki/IEEE_802.11n-2009#Data_rates>`_).
291 |br| By default, ``nss=1``.
292 * ``wifi_distance`` is the distance from a station to the access point. Each station can have its own specific value.
293 It is thus a property of the stations declared inside the WiFi zone.
294 |br| By default, ``wifi_distance=10``.
296 Here is an example of a zone with non-default ``mcs`` and ``nss`` values.
300 <zone id="SSID_1" routing="WIFI">
301 <prop id="access_point" value="alice"/>
302 <prop id="mcs" value="2"/>
303 <prop id="nss" value="2"/>
307 Here is an example of setting the ``wifi_distance`` of a given station.
311 <host id="STA0-0" speed="1Gf">
312 <prop id="wifi_distance" value="37"/>
318 This simplistic network model is one of the few SimGrid network model that is not based on the LMM solver. In this
319 model, all communication take a constant time (one second by default). It provides the lowest level of realism, but is
320 marginally faster and much simpler to understand. This model may reveal interesting if you plan to study abstract
321 distributed algorithms such as leader election or causal broadcast.
325 ns-3 as a SimGrid model
326 ***********************
328 The **ns-3 based model** is the most accurate network model that you can get in SimGrid. It relies on the well-known
329 `ns-3 packet-level network simulator <http://www.nsnam.org>`_ to compute every timing information related to the network
330 transfers of your simulation. For instance, this may be used to investigate the validity of a simulation. Note that this
331 model is much slower than the LMM-based models, because ns-3 simulates the movement of every network packet involved in
332 every communication while SimGrid only recomputes the respective instantaneous speeds of the currently ongoing
333 communications when one communication starts or stops.
335 You need to install ns-3 and recompile SimGrid accordingly to use this model.
337 The SimGrid/ns-3 binding only contains features that are common to both systems. Not all ns-3 models are available from
338 SimGrid (only the TCP and WiFi ones are), while not all SimGrid platform files can be used in conjunction with ns-3
339 (routes must be of length 1). Also, the platform built in ns-3 from the SimGrid
340 description is very basic. Finally, communicating from a host to
341 itself is forbidden in ns-3, so every such communication completes
342 immediately upon startup.
345 Compiling the ns-3/SimGrid binding
346 ==================================
351 SimGrid requires ns-3 version 3.26 or higher, and you probably want the most
352 recent version of both SimGrid and ns-3. While the Debian package of SimGrid
353 does not have the ns-3 bindings activated, you can still use the packaged version
354 of ns-3 by grabbing the ``libns3-dev ns3`` packages. Alternatively, you can
355 install ns-3 from scratch (see the `ns-3 documentation <http://www.nsnam.org>`_).
357 Enabling ns-3 in SimGrid
358 ------------------------
360 SimGrid must be recompiled with the ``enable_ns3`` option activated in cmake.
361 Optionally, use ``NS3_HINT`` to tell cmake where ns3 is installed on
364 .. code-block:: console
366 $ cmake . -Denable_ns3=ON -DNS3_HINT=/opt/ns3 # or change the path if needed
368 By the end of the configuration, cmake reports whether ns-3 was found,
369 and this information is also available in ``include/simgrid/config.h``
370 If your local copy defines the variable ``SIMGRID_HAVE_NS3`` to 1, then ns-3
371 was correctly detected. Otherwise, explore ``CMakeFiles/CMakeOutput.log`` and
372 ``CMakeFiles/CMakeError.log`` to diagnose the problem.
374 Test that ns-3 was successfully integrated with the following command (executed from your SimGrid
375 build directory). It will run all SimGrid tests that are related to the ns-3
376 integration. If no test is run at all, then ns-3 is disabled in cmake.
378 .. code-block:: console
385 If you use a version of ns-3 that is not known to SimGrid yet, edit
386 ``tools/cmake/Modules/FindNS3.cmake`` in your SimGrid tree, according to the
387 comments on top of this file. Conversely, if something goes wrong with an old
388 version of either SimGrid or ns-3, try upgrading everything.
390 Note that there is a known bug with the version 3.31 of ns3 when it is built with
391 MPI support, like it is with the libns3-dev package in Debian 11 « Bullseye ».
392 A simple workaround is to edit the file
393 ``/usr/include/ns3.31/ns3/point-to-point-helper.h`` to remove the ``#ifdef NS3_MPI``
394 include guard. This can be achieved with the following command (as root):
396 .. code-block:: console
398 # sed -i '/^#ifdef NS3_MPI/,+2s,^#,//&,' /usr/include/ns3.31/ns3/point-to-point-helper.h
402 Using ns-3 from SimGrid
403 =======================
405 Platform files compatibility
406 ----------------------------
408 Any route longer than one will be ignored when using ns-3. They are
409 harmless, but you still need to connect your hosts using one-hop routes.
410 The best solution is to add routers to split your route. Here is an
411 example of an invalid platform:
415 <?xml version='1.0'?>
416 <!DOCTYPE platform SYSTEM "https://simgrid.org/simgrid.dtd">
417 <platform version="4.1">
418 <zone id="zone0" routing="Floyd">
419 <host id="alice" speed="1Gf" />
420 <host id="bob" speed="1Gf" />
422 <link id="l1" bandwidth="1Mbps" latency="5ms" />
423 <link id="l2" bandwidth="1Mbps" latency="5ms" />
425 <route src="alice" dst="bob">
426 <link_ctn id="l1"/> <!-- !!!! IGNORED WHEN USED WITH ns-3 !!!! -->
427 <link_ctn id="l2"/> <!-- !!!! ROUTES MUST CONTAIN ONE LINK ONLY !!!! -->
432 This can be reformulated as follows to make it usable with the ns-3 binding.
433 There is no direct connection from alice to bob, but that's OK because ns-3
434 automatically routes from point to point (using
435 ``ns3::Ipv4GlobalRoutingHelper::PopulateRoutingTables``).
439 <?xml version='1.0'?>
440 <!DOCTYPE platform SYSTEM "https://simgrid.org/simgrid.dtd">
441 <platform version="4.1">
442 <zone id="zone0" routing="Full">
443 <host id="alice" speed="1Gf" />
444 <host id="bob" speed="1Gf" />
446 <router id="r1" /> <!-- routers are compute-less hosts -->
448 <link id="l1" bandwidth="1Mbps" latency="5ms"/>
449 <link id="l2" bandwidth="1Mbps" latency="5ms"/>
451 <route src="alice" dst="r1">
455 <route src="r1" dst="bob">
461 Once your platform is OK, just change the :ref:`network/model
462 <options_model_select>` configuration option to `ns-3` as follows. The other
463 options can be used as usual.
465 .. code-block:: console
467 $ ./network-ns3 --cfg=network/model:ns-3 (other parameters)
469 Many other files from the ``examples/platform`` directory are usable with the
470 ns-3 model, such as `examples/platforms/dogbone.xml <https://framagit.org/simgrid/simgrid/tree/master/examples/platforms/dogbone.xml>`_.
471 Check the file `examples/cpp/network-ns3/network-ns3.tesh <https://framagit.org/simgrid/simgrid/tree/master/examples/cpp/network-ns3/network-ns3.tesh>`_
472 to see which ones are used in our regression tests.
474 Alternatively, you can manually modify the ns-3 settings by retrieving
475 the ns-3 node from any given host with the
476 :cpp:func:`simgrid::get_ns3node_from_sghost` function (defined in
477 ``simgrid/plugins/ns3.hpp``).
479 .. doxygenfunction:: simgrid::get_ns3node_from_sghost
483 It is possible to define a fixed or random seed to the ns3 random number generator using the config tag.
487 <?xml version='1.0'?><!DOCTYPE platform SYSTEM "https://simgrid.org/simgrid.dtd">
488 <platform version="4.1">
490 <prop id = "network/model" value = "ns-3" />
491 <prop id = "ns3/seed" value = "time" />
496 The first property defines that this platform will be used with the ns3 model.
497 The second property defines the seed that will be used. Defined to ``time``,
498 it will use a random seed, defined to a number it will use this number as
504 A ns-3 platform is automatically created from the provided SimGrid
505 platform. However, there are some known caveats:
507 * The default values (e.g., TCP parameters) are the ns-3 default values.
508 * ns-3 networks are routed using the shortest path algorithm, using ``ns3::Ipv4GlobalRoutingHelper::PopulateRoutingTables``.
509 * End hosts cannot have more than one interface card. So, your SimGrid hosts
510 should be connected to the platform through only one link. Otherwise, your
511 SimGrid host will be considered as a router (FIXME: is it still true?).
513 Our goal is to keep the ns-3 plugin of SimGrid as easy (and hopefully readable)
514 as possible. If the current state does not fit your needs, you should modify
515 this plugin, and/or create your own plugin from the existing one. If you come up
516 with interesting improvements, please contribute them back.
521 If your simulation hangs in a communication, this is probably because one host
522 is sending data that is not routable in your platform. Make sure that you only
523 use routes of length 1, and that any host is connected to the platform.
524 Arguably, SimGrid could detect this situation and report it, but unfortunately,
525 this still has to be done.
530 `FMI <https://fmi-standard.org/>`_ is a standard to exchange models between simulators. If you want to plug such a model
531 into SimGrid, you need the `SimGrid-FMI external plugin <https://framagit.org/simgrid/simgrid-FMI>`_.
532 There is a specific `documentation <https://simgrid.frama.io/simgrid-FMI/index.html>`_ available for the plugin.
533 This was used to accurately study a *Smart grid* through co-simulation: `PandaPower <http://www.pandapower.org/>`_ was
534 used to simulate the power grid, `ns-3 <https://nsnam.org/>`_ was used to simulate the communication network while SimGrid was
535 used to simulate the IT infrastructure. Please also refer to the `relevant publication <https://hal.science/hal-03217562>`_
543 As for any simulator, models are very important components of the SimGrid toolkit. Several kind of models are used in
544 SimGrid beyond the performance models described above:
546 The **routing models** constitute advanced elements of the platform description. This description naturally entails
547 :ref:`components<platform>` that are very related to the performance models. For instance, determining the execution
548 time of a task obviously depends on the characteristics of the machine that executes this task. Furthermore, networking
549 zones can be interconnected to compose larger platforms `in a scalable way <http://hal.inria.fr/hal-00650233/>`_. Each
550 of these zones can be given a specific :ref:`routing model<platform_routing>` that efficiently computes the list of
551 links forming a network path between two given hosts.
553 The model checker uses an abstraction of the performance simulations. Mc SimGrid explores every causally possible
554 execution paths of the application, completely abstracting the performance away. The simulated time is not even
555 computed in this mode! The abstraction involved in this process also models the mutual impacts among actions, to not
556 re-explore histories that only differ by the order of independent and unrelated actions. As with the rest of the model
557 checker, these models are unfortunately still to be documented properly.