-.. _platform:
-
.. raw:: html
<object id="TOC" data="graphical-toc.svg" type="image/svg+xml"></object>
Of course, this is only one possible way to model these things. YMMV ;)
+.. _howto_parallel_links:
+
+Modeling parallel links
+***********************
+
+Most HPC topologies, such as fat-trees, allow parallel links (a
+router A and a router B can be connected by more than one link).
+You might be tempted to model this configuration as follows :
+
+.. code-block:: xml
+
+ <router id="routerA"/>
+ <router id="routerB"/>
+
+ <link id="link1" bandwidth="10GBps" latency="2us"/>
+ <link id="link2" bandwidth="10GBps" latency="2us"/>
+
+ <route src="routerA" dst="routerB">
+ <link_ctn id="link1"/>
+ </route>
+ <route src="routerA" dst="routerB">
+ <link_ctn id="link2"/>
+ </route>
+
+But that will not work, since SimGrid doesn't allow several routes for
+a single `{src ; dst}` pair. Instead, what you should do is :
+
+ - Use a single route with both links (so both will be traversed
+ each time a message is exchanged between router A and B)
+
+ - Double the bandwidth of one link, to model the total bandwidth of
+ both links used in parallel. This will make sure no combined
+ communications between router A and B use more than the bandwidth
+ of two links
+
+ - Assign the other link a `FATPIPE` sharing policy, which will allow
+ several communications to use the full bandwidth of this link without
+ having to share it. This will model the fact that individual
+ communications can use at most this link's bandwidth
+
+ - Set the latency of one of the links to 0, so that latency is only
+ accounted for once (since both link are traversed by each message)
+
+So the final platform for our example becomes :
+
+.. code-block:: xml
+
+ <router id="routerA"/>
+ <router id="routerB"/>
+
+ <!-- This link limits the total bandwidth of all parallel communications -->
+ <link id="link1" bandwidth="20GBps" latency="2us"/>
+
+ <!-- This link only limits the bandwidth of individual communications -->
+ <link id="link2" bandwidth="10GBps" latency="0us" sharing_policy="FATPIPE"/>
+
+ <!-- Each message traverses both links -->
+ <route src="routerA" dst="routerB">
+ <link_ctn id="link1"/>
+ <link_ctn id="link2"/>
+ </route>
+
.. _understanding_lv08
Understanding the default TCP model
.. code-block:: xml
- <host id="A" speed="1Gf"/>
- <host id="B" speed="1Gf"/>
+ <host id="A" speed="1Gf" />
+ <host id="B" speed="1Gf" />
- <link id="link1" latency="10ms" bandwidth="1Mbps"/>
+ <link id="link1" latency="10ms" bandwidth="1Mbps" />
- <route src="A" dst="B>
- <link_ctn id="link1/>
+ <route src="A" dst="B">
+ <link_ctn id="link1" />
</route>
If host `A` sends `100kB` (a hundred kilobytes) to host `B`, one could expect
- 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 route from B to A is implicity declared in the
- platfrom file and uses the same link `link1` as if the two hosts were
+ consumption of `0.05`. The route from B to A is implicitly declared in the
+ platform file and uses the same link `link1` as if the two hosts were
connected through a communication bus. The bandwidth share allocated to the
flow from A to B is then the available bandwidth of `link1` (i.e., 97% of
the nominal bandwidth of 1Mb/s) divided by 1.05 (i.e., the total consumption).
