docs/source/platform_howtos.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("PlatformBox")
   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 .. _howto:
  14
  15 Modeling Hints
  16 ##############
  17
  18 There is no perfect model. Only models that are adapted to the
  19 specific study that you want to do. SimGrid provides several advanced
  20 mechanisms that you can adapt to model the situation that you are
  21 interested in, and it is often uneasy to see where to start with.
  22 This page collects several hints and tricks on modeling situations.
  23 Even if you are looking for a very advanced, specific use case, these
  24 examples may help you to design the solution you need.
  25
  26 .. _howto_science:
  27
  28 Doing Science with SimGrid
  29 **************************
  30
  31 Many users are using SimGrid as a scientific instrument for their
  32 research. This tool was indeed invented to that extent, and we strive
  33 to streamline this kind of usage. But SimGrid is no magical tool, and
  34 it is of your responsibility that the tool actually provides sensible
  35 results. Fortunately, there is a vast literature on how to avoid
  36 Modeling & Simulations pitfalls. We review here some specific works.
  37
  38 In `An Integrated Approach to Evaluating Simulation Credibility
  39 <http://www.dtic.mil/dtic/tr/fulltext/u2/a405051.pdf>`_, the authors
  40 provide a methodology enabling the users to increase their confidence
  41 in the simulation tools they use. First of all, you must know what you
  42 actually expect to discover whether the tool actually covers your
  43 needs. Then, as they say, "a fool with a tool is still a fool", so you
  44 need to think about your methodology before you submit your articles.
  45 `Towards a Credibility Assessment of Models and Simulations
  46 <https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20080015742.pdf>`_
  47 gives a formal methodology to assess the credibility of your
  48 simulation results.
  49
  50 `Seven Pitfalls in Modeling and Simulation Research
  51 <https://dl.acm.org/citation.cfm?id=2430188>`_ is even more
  52 specific. Here are the listed pitfalls: (1) Don't know whether it's
  53 modeling or simulation, (2) No separation of concerns, (3) No clear
  54 scientific question, (4) Implementing everything from scratch, (5)
  55 Unsupported claims, (6) Toy duck approach, and (7) The tunnel view. As
  56 you can see, this article is a must read. It's a pity that it's not
  57 freely available, though.
  58
  59 .. _howto_churn:
  60
  61 Modeling Churn (e.g., in P2P)
  62 *****************************
  63
  64 One of the biggest challenges in P2P settings is to cope with the
  65 churn, meaning that resources keep appearing and disappearing. In
  66 SimGrid, you can always change the state of each host manually, with
  67 eg :cpp:func:`simgrid::s4u::Host::turn_on`. To reduce the burden when
  68 the churn is high, you can also attach a **state profile** to the host
  69 directly.
  70
  71 This can be done through the XML file, using the ``state_file``
  72 attribute of :ref:`pf_tag_host`, :ref:`pf_tag_cluster` or
  73 :ref:`pf_tag_link`. Every line (but the last) of such files describes
  74 timed events with the form "date value". Example:
  75
  76 .. code-block:: python
  77
  78    1 0
  79    2 1
  80    LOOPAFTER 8
  81
  82   - At time t = 1, the host is turned off (a zero value means OFF)
  83   - At time t = 2, the host is turned back on (any other value than zero means ON)
  84   - At time t = 10, the profile is reset (as we are 8 seconds after the last event). Then the host will be turned off
  85     again at time t = 11.
  86
  87    If your profile does not contain any LOOPAFTER line, then it will be executed only once and not in a repetitive way.
  88
  89 Another possibility is to use the
  90 :cpp:func:`simgrid::s4u::Host::set_state_profile()` or
  91 :cpp:func:`simgrid::s4u::Link::set_state_profile()` functions. These
  92 functions take a profile, that can be a fixed profile exhaustively
  93 listing the events, or something else if you wish.
  94
  95 .. _howto_multicore:
  96
  97 Modeling Multicore Machines
  98 ***************************
  99
 100 Default Model
 101 =============
 102
 103 Multicore machines are very complex, and there are many ways to model
 104 them. The default models of SimGrid are coarse grain and capture some
 105 elements of this reality. Here is how to declare simple multicore hosts:
 106
 107 .. code-block:: xml
 108
 109    <host id="mymachine" speed="8Gf" core="4"/>
 110
 111 It declares a 4-core host called "mymachine", each core computing 8
 112 GFlops per second. If you put one activity of 8 GFlops on this host, it
 113 will be computed in 1 second (by default, activities are
 114 single-threaded and cannot leverage the computing power of more than
 115 one core). If you run two such activities simultaneously, they will still be
 116 computed in one second, and so on up to 4 activities. If you start 5 activities,
 117 they will share the total computing power, and each activity will be
 118 computed in 5/4 = 1.25 seconds. This is a very simple model, but that is
 119 all what you get by default from SimGrid.
 120
 121 Pinning tasks to cores
 122 ======================
 123
 124 The default model does not account for task pinning, where you
 125 manually select on which core each of the existing activity should
 126 execute. The best solution to model this is probably to model your
 127 4-core processor as 4 distinct hosts, and assigning the activities to
 128 cores by migrating them to the declared hosts. In some sense, this
 129 takes the whole Network-On-Chip idea really seriously.
 130
 131 Some extra complications may arise here. If you have more activities than
 132 cores, you'll have to `schedule your activities
 133 <https://en.wikipedia.org/wiki/Scheduling_%28computing%29#Operating_system_process_scheduler_implementations)>`_
 134 yourself on the cores (so you'd better avoid this complexity). Since
 135 you cannot have more than one network model in a given SimGrid
 136 simulation, you will end up with a TCP connection between your cores. A
 137 possible work around is to never start any simulated communication
 138 between the cores and have the same routes from each core to the
 139 rest of the external network.
 140
 141 Modeling a multicore CPU as a set of SimGrid hosts may seem strange
 142 and unconvincing, but some users achieved very realistic simulations
 143 of multicore and GPU machines this way.
 144
 145 Modeling machine boot and shutdown periods
 146 ********************************************
 147
 148 When a physical host boots up, a lot of things happen. It takes time
 149 during which the machine is not usable but dissipates energy, and
 150 programs actually die and restart during a reboot. Since there are many
 151 ways to model it, SimGrid does not do any modeling choice for you but
 152 the most obvious ones.
 153
 154 Any actor (or process in MSG) running on a host that is shut down
 155 will be killed and all its activities (tasks in MSG) will be
 156 automatically canceled. If the actor killed was marked as
 157 auto-restartable (with
 158 :cpp:func:`simgrid::s4u::Actor::set_auto_restart` or with
 159 :cpp:func:`MSG_process_auto_restart_set`), it will start anew with the
 160 same parameters when the host boots back up.
 161
 162 By default, shutdowns and boots are instantaneous. If you want to
 163 add an extra delay, you have to do that yourself, for example from a
 164 `controller` actor that runs on another host. The best way to do so is
 165 to declare a fictional pstate where the CPU delivers 0 flop per
 166 second (so every activity on that host will be frozen when the host is
 167 in this pstate). When you want to switch the host off, your controller
 168 switches the host to that specific pstate (with
 169 :cpp:func:`simgrid::s4u::Host::set_pstate`), waits for the amount of
 170 time that you decided necessary for your host to shut down, and turns
 171 the host off (with :cpp:func:`simgrid::s4u::Host::turn_off`). To boot
 172 up, switch the host on, go into the specific pstate, wait a while and
 173 go to a more regular pstate.
 174
 175 To model the energy dissipation, you need to put the right energy
 176 consumption in your startup/shutdown specific pstate. Remember that
 177 the energy consumed is equal to the instantaneous consumption
 178 multiplied by the time in which the host keeps in that state. Do the
 179 maths, and set the right instantaneous consumption to your pstate, and
 180 you'll get the whole boot period to consume the amount of energy that
 181 you want. You may want to have one fictional pstate for the boot
 182 period and another one for the shutdown period.
 183
 184 Of course, this is only one possible way to model these things. YMMV ;)
 185
 186 .. _understanding_lv08
 187
 188 Understanding the default TCP model
 189 ***********************************
 190 When simulating a data transfer between two hosts, you may be surprised
 191 by the obtained simulation time. Lets consider the following platform:
 192
 193 .. code-block:: xml
 194
 195    <host id="A" speed="1Gf" />
 196    <host id="B" speed="1Gf" />
 197
 198    <link id="link1" latency="10ms" bandwidth="1Mbps" />
 199
 200    <route src="A" dst="B">
 201      <link_ctn id="link1" />
 202    </route>
 203
 204 If host `A` sends `100kB` (a hundred kilobytes) to host `B`, one could expect
 205 that this communication would take `0.81` seconds to complete according to a
 206 simple latency-plus-size-divided-by-bandwidth model (0.01 + 8e5/1e6 = 0.81).
 207 However, the default TCP model of SimGrid is a bit more complex than that. It
 208 accounts for three phenomena that directly impact the simulation time even
 209 on such a simple example:
 210
 211   - The size of a message at the application level (i.e., 100kB in this
 212     example) is not the size that will actually be transferred over the
 213     network. To mimic the fact that TCP and IP headers are added to each packet of
 214     the original payload, the TCP model of SimGrid empirically considers that
 215     `only 97% of the nominal bandwidth` are available. In other words, the
 216     size of your message is increased by a few percents, whatever this size be.
 217
 218   - In the real world, the TCP protocol is not able to fully exploit the
 219     bandwidth of a link from the emission of the first packet. To reflect this
 220     `slow start` phenomenon, the latency declared in the platform file is
 221     multiplied by `a factor of 13.01`. Here again, this is an empirically
 222     determined value that may not correspond to every TCP implementations on
 223     every networks. It can be tuned when more realistic simulated times for
 224     short messages are needed though.
 225
 226   - When data is transferred from A to B, some TCP ACK messages travel in the
 227     opposite direction. To reflect the impact of this `cross-traffic`, SimGrid
 228     simulates a flow from B to A that represents an additional bandwidth
 229     consumption of `0.05`. The route from B to A is implicity declared in the
 230     platfrom file and uses the same link `link1` as if the two hosts were
 231     connected through a communication bus. The bandwidth share allocated to the
 232     flow from A to B is then the available bandwidth of `link1` (i.e., 97% of
 233     the nominal bandwidth of 1Mb/s) divided by 1.05 (i.e., the total consumption).
 234     This feature, activated by default, can be disabled by adding the
 235     `--cfg=network/crosstraffic:0` flag to command line.
 236
 237 As a consequence, the time to transfer 100kB from A to B as simulated by the
 238 default TCP model of SimGrid is not 0.81 seconds but
 239
 240 .. code-block:: python
 241
 242     0.01 * 13.01 + 800000 / ((0.97 * 1e6) / 1.05) =  0.996079 seconds.