communications are not slowed down, because there is no contention yet).
As an alternative to the above LMM-based models, it is possible to use the :ref:`ns-3 simulator as a network model <models_ns3>`. ns-3 performs
-a mushc more detailed, packet-level simulation
+a much more detailed, packet-level simulation
than the above models. As a result is is much slower but will produce more accurate results.
Both simulators have time complexity that is linear in the size of their input, but ns-3 has a much larger input in case of large communications
because it considers individual network packets.
<link_ctn id="link1" />
</route>
-If host `A` sends ``100kB`` (a hundred kilobytes) to host `B`, one can expect that this communication would take `0.81`
-seconds to complete according to a simple latency-plus-size-divided-by-bandwidth model (0.01 + 8e5/1e6 = 0.81) since the
-latency is small enough to ensure that the physical bandwidth is used (see the discussion on CM02 above). However, the
-LV08 model is more complex to account for three phenomena that directly impact the simulation time:
+If host `A` sends ``100kB`` (a hundred kilobytes, that is, 8e5 bits) to host `B`, one can expect that this communication would
+take `0.81` seconds to complete according to a simple latency-plus-size-divided-by-bandwidth model (0.01 + 8e5/1e6 = 0.81 -- the
+size was converted from bytes to bits) since the latency is small enough to ensure that the physical bandwidth is used (see the
+discussion on CM02 above). However, the LV08 model is more complex to account for three phenomena that directly impact the
+simulation time:
- The size of a message at the application level (i.e., 100kB in this example) is not the size that is actually
transferred over the network. To mimic the fact that TCP and IP headers are added to each packet of the original
payload, the TCP model of SimGrid empirically considers that `only 97% of the nominal bandwidth` are available. In
- other words, the size of your message is increased by a few percents, whatever this size be.
+ other words, the size of your message is increased by a few percents, whichever this size.
- In the real world, the TCP protocol is not able to fully exploit the bandwidth of a link from the emission of the
first packet. To reflect this `slow start` phenomenon, the latency declared in the platform file is multiplied by
ns-3 as a SimGrid model
***********************
-The **ns-3 based model** is the most accurate network model in SimGrid. It relies on the well-known
-`ns-3 packet-level network simulator <http://www.nsnam.org>`_ to compute full timing information related to network
-transfers. This
-model is much slower than the LMM-based models. This is because ns-3 simulates the movement of every network packet involved in
-every communication, while the LMM-based models only recompute the respective instantaneous speeds of the currently ongoing
-communications when a communication starts or stops.
+The **ns-3 based model** is the most accurate network model in SimGrid. It relies on the well-known `ns-3 packet-level network
+simulator <http://www.nsnam.org>`_ to compute full timing information related to network transfers. This model is much slower
+than the LMM-based models. This is because ns-3 simulates the movement of every network packet involved in every communication,
+while the LMM-based models only recompute the respective instantaneous speeds of the currently ongoing communications when a
+communication starts or stops. In other terms, both SimGrid and ns-3 are fast and highly optimized, but while SimGrid only
+depends on application-level events (starting and stoping of communications), ns-3 depends on network-level events (sending a
+packet).
You need to install ns-3 and recompile SimGrid accordingly to use this model.
-The SimGrid/ns-3 binding only contains features that are common to both systems. Not all ns-3 models are available from
-SimGrid (only the TCP and WiFi ones are), while not all SimGrid platform files can be used in conjunction with ns-3
-(routes must be of length 1). Note also that the platform built in ns-3 from the SimGrid
-description is very basic. Finally, communicating from a host to
-itself is forbidden in ns-3, so every such communication is simulated to take zero time.
+The SimGrid/ns-3 binding only contains features that are common to both systems. Not all ns-3 models are available from SimGrid
+(only the TCP and WiFi ones are), while not all SimGrid platform files can be used in conjunction with ns-3 (routes must be of
+length 1). Note also that the platform built in ns-3 from the SimGrid description is very basic. Finally, communicating from a
+host to itself is forbidden in ns-3, so every such communication is simulated to take zero time.
+By default, the ns-3 model in SimGrid is not idempotent, unless you patch your version of ns-3 with [this
+patch](https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1338). It is perfectly OK to have a non-idempotent model in SimGrid as
+long as you only have only one such model, and as long as you don't use utterly advanced things in SimGrid. If you do want to
+have an idempotent ns-3, apply the previously mentioned patch, and recompile SimGrid. It should detect the patch and react
+accordingly.
Compiling the ns-3/SimGrid binding
==================================
