However, the default TCP model of SimGrid is a bit more complex than that. It
accounts for three phenomena that directly impacts the simulation time even
on such a simple example:
- - The size of a message at the application level (i.e., 100kB in this
+ - The size of a message at the application level (i.e., 100kB in this
example) is not the size of what will actually be transferred over the
network. To mimic the fact that TCP and IP header 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 works, the
size of your message is increased by a few percents, whatever this size be.
- - In the real world, the TCP protocol is not able to fully exploit the
+ - 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 `a factor of 13.01`. Here again, this is an empirically
every networks. It can be tuned when more realistic simulated times for
short messages are needed though.
- - When data is transferred from A to B, some TCP ACK messages travel in the
+ - When data is transferred from A to B, some TCP ACK messages travel in the
opposite direction. To reflect the impact of this `cross-traffic`, SimGrid
simulates a flow from B to A that represents an additional bandwidth
consumption of `0.05`. The bandwidth share allocated to the flow from A to
0.81 seconds but
.. code-block:: python
- 0.01 * 13.01 + 800000 / (0.97*1e6)/1.05) = 0.996079 seconds
\ No newline at end of file
+
+ 0.01 * 13.01 + 800000 / ((0.97 * 1e6) / 1.05) = 0.996079 seconds
