docs/source/platform.rst

   1 .. _platform:
   2
   3 .. raw:: html
   4
   5    <object id="TOC" data="graphical-toc.svg" width="100%" type="image/svg+xml"></object>
   6    <script>
   7    window.onload=function() { // Wait for the SVG to be loaded before changing it
   8      var elem=document.querySelector("#TOC").contentDocument.getElementById("PlatformBox")
   9      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";
  10    }
  11    </script>
  12    <br/>
  13    <br/>
  14
  15 Describing your Simulated Platform
  16 ##################################
  17
  18 In SimGrid, platforms are usually described in XML. This formalism has
  19 some drawbacks, but using a specific format ensures that the platform
  20 is not mixed with the tested application. This separation of concern
  21 :ref:`is a must <howto_science>` for your Modeling and Simulation (M&S)
  22 work. When XML is too limiting, you may describe your platforms using
  23 the :ref:`lua bindings <platform_lua>` (it is not yet possible to do so in
  24 python or directly in C++).
  25
  26 We understand that writing a complex platform description can be tricky, we thus included
  27 :ref:`many examples <platform_examples>` in the archive. This
  28 documentation also contains some :ref:`hints and howtos <howto>`, as well
  29 as the full :ref:`XML reference guide <platform_reference>`.
  30
  31
  32 Any simulated platform must contain **basic elements**, such as hosts, links, storages, etc. SimGrid gives you a great
  33 liberty when defining the **routing of your platform**, i.e., the network path taken between each pair of hosts.
  34 Finally, you may also describe an **experimental scenario**, with qualitative (e.g., bandwidth variations representing
  35 an external load) and qualitative (e.g., representing how some elements fail and restart over time) changes.
  36
  37
  38 First Example
  39 *************
  40
  41 Imagine you want to describe a little platform with three hosts,
  42 interconnected as follows:
  43
  44 .. image:: /tuto_smpi/3hosts.png
  45    :align: center
  46
  47 This can be done with the following platform file, that considers the
  48 simulated platform as a graph of hosts and network links.
  49
  50 .. literalinclude:: /tuto_smpi/3hosts.xml
  51    :language: xml
  52
  53 The most important elements are the basic ones: :ref:`pf_tag_host`,
  54 :ref:`pf_tag_link`, and similar. Then come the routes between any pair
  55 of hosts, that are given explicitely with :ref:`pf_tag_route` (routes
  56 are symmetrical by default). Any host must be given a computational
  57 speed (in flops) while links must be given a latency (in seconds) and
  58 a bandwidth (in bytes per second). Note that you can write 1Gflops
  59 instead of 1000000000flops, and similar.
  60
  61 Every platform element must be located within a given **networking
  62 zone** .  Zones are in
  63 charge of the routing, see below.
  64
  65 The last thing you must know on SimGrid platform files is that the
  66 root tag must be :ref:`pf_tag_platform`. If the ``version`` attribute
  67 does not match what SimGrid expects, you will be hinted to use to the
  68 ``simgrid_update_xml`` utility to update your file.
  69
  70
  71 Defining a Routing
  72 ******************
  73
  74 Networking zones (:ref:`pf_tag_zone`) are used to factorize the description
  75 to reduce the size of your platform on disk and in memory. Then, when
  76 a host wants to communicate with another host belonging to the same
  77 zone, it is the zone's duty to find the list of links that are
  78 involved in the communication. In the above example, since we use
  79 ``routing="Full"``, all routes must be explicitly given using the
  80 :ref:`pf_tag_route` and :ref:`pf_tag_link_ctn` tags (this :ref:`routing
  81 model <pf_rm>` is both simple and inefficient :) It is OK to not
  82 specify each and every route between hosts, as long as you do not try
  83 to start a communication on any of the missing routes during your
  84 simulation.
  85
  86 Any zone may contain sub-zones, allowing for a hierarchical
  87 decomposition of the platform. Routing can be made more efficient (as the
  88 inter-zone routing gets factored with :ref:`pf_tag_zoneroute`), and
  89 allows you to have more than one routing model in your platform. For
  90 example, you can have a coordinate-based routing for the WAN parts
  91 of your platforms, a full routing within each datacenter, and a highly
  92 optimized routing within each cluster of the datacenter.  In this
  93 case, determining the route between two given hosts gets :ref:`routing_basics`
  94 "somewhat more complex" but SimGrid still computes
  95 these routes for you in a time- and space-efficient manner.
  96 Here is an illustration of these concepts:
  97
  98 .. image:: img/zone_hierarchy.png
  99
 100 Circles represent processing units and squares represent network
 101 routers. Bold lines represent communication links. The zone "AS2" models the core of a national network interconnecting a
 102 small flat cluster (AS4) and a larger hierarchical cluster (AS5), a
 103 subset of a LAN (AS6), and a set of peers scattered around the world
 104 (AS7).
 105
 106 .. todo:: Add more examples, such as the cloud example described in
 107           previous paragraph
 108
 109 Performance Profiles and Churn
 110 ******************************
 111
 112 ..  LocalWords:  SimGrid