docs/source/Platform_Examples.rst

   1 .. raw:: html
   2
   3    <object id="TOC" data="graphical-toc.svg" type="image/svg+xml"></object>
   4    <script>
   5    window.onload=function() { // Wait for the SVG to be loaded before changing it
   6      var elem=document.querySelector("#TOC").contentDocument.getElementById("ExamplesBox")
   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";
   8    }
   9    </script>
  10    <br/>
  11    <br/>
  12
  13 .. _platform_examples:
  14
  15 Platform Examples
  16 =================
  17
  18 Simple Example with 3 hosts
  19 ---------------------------
  20
  21 Imagine you want to describe a little platform with three hosts,
  22 interconnected as follows:
  23
  24 .. image:: /tuto_smpi/3hosts.png
  25    :align: center
  26
  27 This can be done with the following platform file, that considers the
  28 simulated platform as a graph of hosts and network links.
  29
  30 .. literalinclude:: /tuto_smpi/3hosts.xml
  31    :language: xml
  32
  33 The elements basic elements (with :ref:`pf_tag_host` and
  34 :ref:`pf_tag_link`) are described first, and then the routes between
  35 any pair of hosts are explicitly given with :ref:`pf_tag_route`.
  36
  37 Any host must be given a computational speed in flops while links must
  38 be given a latency and a bandwidth. You can write 1Gf for
  39 1,000,000,000 flops (full list of units in the reference guide of
  40 :ref:`pf_tag_host` and :ref:`pf_tag_link`).
  41
  42 Routes defined with :ref:`pf_tag_route` are symmetrical by default,
  43 meaning that the list of traversed links from A to B is the same as
  44 from B to A. Explicitly define non-symmetrical routes if you prefer.
  45
  46 Cluster with a Crossbar
  47 -----------------------
  48
  49 A very common parallel computing platform is a homogeneous cluster in
  50 which hosts are interconnected via a crossbar switch with as many
  51 ports as hosts, so that any disjoint pairs of hosts can communicate
  52 concurrently at full speed. For instance:
  53
  54 .. literalinclude:: ../../examples/platforms/cluster_crossbar.xml
  55    :language: xml
  56    :lines: 1-3,18-
  57
  58 One specifies a name prefix and suffix for each host, and then give an
  59 integer range. In the example the cluster contains 65535 hosts (!),
  60 named ``node-0.simgrid.org`` to ``node-65534.simgrid.org``. All hosts
  61 have the same power (1 Gflop/sec) and are connected to the switch via
  62 links with same bandwidth (125 MBytes/sec) and latency (50
  63 microseconds).
  64
  65 .. todo::
  66
  67    Add the picture.
  68
  69 Cluster with a Shared Backbone
  70 ------------------------------
  71
  72 Another popular model for a parallel platform is that of a set of
  73 homogeneous hosts connected to a shared communication medium, a
  74 backbone, with some finite bandwidth capacity and on which
  75 communicating host pairs can experience contention. For instance:
  76
  77
  78 .. literalinclude:: ../../examples/platforms/cluster_backbone.xml
  79    :language: xml
  80    :lines: 1-3,18-
  81
  82 The only differences with the crossbar cluster above are the ``bb_bw``
  83 and ``bb_lat`` attributes that specify the backbone characteristics
  84 (here, a 500 microseconds latency and a 2.25 GByte/sec
  85 bandwidth). This link is used for every communication within the
  86 cluster. The route from ``node-0.simgrid.org`` to ``node-1.simgrid.org``
  87 counts 3 links: the private link of ``node-0.simgrid.org``, the backbone
  88 and the private link of ``node-1.simgrid.org``.
  89
  90 .. todo::
  91
  92    Add the picture.
  93
  94 Torus Cluster
  95 -------------
  96
  97 Many HPC facilities use torus clusters to reduce sharing and
  98 performance loss on concurrent internal communications. Modeling this
  99 in SimGrid is very easy. Simply add a ``topology="TORUS"`` attribute
 100 to your cluster. Configure it with the ``topo_parameters="X,Y,Z"``
 101 attribute, where ``X``, ``Y`` and ``Z`` are the dimension of your
 102 torus.
 103
 104 .. image:: ../../examples/platforms/cluster_torus.svg
 105    :align: center
 106
 107 .. literalinclude:: ../../examples/platforms/cluster_torus.xml
 108    :language: xml
 109
 110 Note that in this example, we used ``loopback_bw`` and
 111 ``loopback_lat`` to specify the characteristics of the loopback link
 112 of each node (i.e., the link allowing each node to communicate with
 113 itself). We could have done so in previous example too. When no
 114 loopback is given, the communication from a node to itself is handled
 115 as if it were two distinct nodes: it goes twice through the private
 116 link and through the backbone (if any).
 117
 118 Fat-Tree Cluster
 119 ----------------
 120
 121 This topology was introduced to reduce the amount of links in the
 122 cluster (and thus reduce its price) while maintaining a high bisection
 123 bandwidth and a relatively low diameter. To model this in SimGrid,
 124 pass a ``topology="FAT_TREE"`` attribute to your cluster. The
 125 ``topo_parameters=#levels;#downlinks;#uplinks;link count`` follows the
 126 semantic introduced in the `Figure 1B of this article
 127 <http://webee.eedev.technion.ac.il/wp-content/uploads/2014/08/publication_574.pdf>`_.
 128
 129 Here is the meaning of this example: ``2 ; 4,4 ; 1,2 ; 1,2``
 130
 131 - That's a two-level cluster (thus the initial ``2``).
 132 - Routers are connected to 4 elements below them, regardless of its
 133   level. Thus the ``4,4`` component that is used as
 134   ``#downlinks``. This means that the hosts are grouped by 4 on a
 135   given router, and that there is 4 level-1 routers (in the middle of
 136   the figure).
 137 - Hosts are connected to only 1 router above them, while these routers
 138   are connected to 2 routers above them (thus the ``1,2`` used as
 139   ``#uplink``).
 140 - Hosts have only one link to their router while every path between a
 141   level-1 routers and level-2 routers use 2 parallel links. Thus the
 142   ``1,2`` that is used as ``link count``.
 143
 144 .. image:: ../../examples/platforms/cluster_fat_tree.svg
 145    :align: center
 146
 147 .. literalinclude:: ../../examples/platforms/cluster_fat_tree.xml
 148    :language: xml
 149    :lines: 1-3,10-
 150
 151
 152 Dragonfly Cluster
 153 -----------------
 154
 155 This topology was introduced to further reduce the amount of links
 156 while maintaining a high bandwidth for local communications. To model
 157 this in SimGrid, pass a ``topology="DRAGONFLY"`` attribute to your
 158 cluster. It's based on the implementation of the topology used on
 159 Cray XC systems, described in paper
 160 `Cray Cascade: A scalable HPC system based on a Dragonfly network <https://dl.acm.org/citation.cfm?id=2389136>`_.
 161
 162 System description follows the format ``topo_parameters=#groups;#chassis;#routers;#nodes``
 163 For example, ``3,4 ; 3,2 ; 3,1 ; 2``:
 164
 165 - ``3,4``: There are 3 groups with 4 links between each (blue level).
 166   Links to nth group are attached to the nth router of the group
 167   on our implementation.
 168 - ``3,2``: In each group, there are 3 chassis with 2 links between each nth router
 169   of each group (black level)
 170 - ``3,1``: In each chassis, 3 routers are connected together with a single link
 171   (green level)
 172 - ``2``: Each router has two nodes attached (single link)
 173
 174 .. image:: ../../examples/platforms/cluster_dragonfly.svg
 175    :align: center
 176
 177 .. literalinclude:: ../../examples/platforms/cluster_dragonfly.xml
 178    :language: xml
 179
 180
 181 .. todo:: Complete this page of the manual.
 182
 183    SimGrid comes with an extensive set of platforms in the
 184    `examples/platforms <https://framagit.org/simgrid/simgrid/tree/master/examples/platforms>`_
 185    directory that should be described here.
 186