docs/source/platform_howtos.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 .. _howto:
  16
  17 Modeling Hints
  18 ##############
  19
  20 There is no perfect model, but only models that are adapted to the
  21 specific study that you want to do. SimGrid provide several advanced
  22 mechanisms that you can adapt to model the situation that you are
  23 interested into, and it is often uneasy to see where to start with.
  24 This page collects several hints and tricks on modeling situations.
  25 Even if you are looking for a very advanced, specific use case, these
  26 examples may help you to design the solution you need.
  27
  28 .. _howto_science:
  29
  30 Doing Science with SimGrid
  31 **************************
  32
  33 Many users are using SimGrid as a scientific instrument for their
  34 research. This tool was indeed invented to that extend, and we strive
  35 to streamline this kind of usage. But SimGrid is no magical tool, and
  36 it is of your responsability that the tool actually provides sensible
  37 results. Fortunately, there is a vast literature on how to avoid
  38 Modeling & Simulations pitfalls. We review here some specific works.
  39
  40 In `An Integrated Approach to Evaluating Simulation Credibility
  41 <http://www.dtic.mil/dtic/tr/fulltext/u2/a405051.pdf>`_, the authors
  42 provide a methodology enabling the users to increase their confidence
  43 in the simulation tools they use. First of all, you must know what you
  44 actually expect to discover whether the tool actually covers your
  45 needs. Then, as they say, "a fool with a tool is still a fool", so you
  46 need to think about your methodology before you submit your articles.
  47 `Towards a Credibility Assessment of Models and Simulations
  48 <https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20080015742.pdf>`_
  49 gives a formal methodology to assess the credibility of your
  50 simulation results.
  51
  52 `Seven Pitfalls in Modeling and Simulation Research
  53 <https://dl.acm.org/citation.cfm?id=2430188>`_ is even more
  54 specific. Here are the listed pitfalls: (1) Don't know whether it's
  55 modeling or simulation, (2) No separation of concerns, (3) No clear
  56 scientific question, (4) Implementing everything from scratch, (5)
  57 Unsupported claims, (6) Toy duck approach, and (7) The tunnel view. As
  58 you can see, this article is a must read. It's a pitty that it's not
  59 freely available, though.
  60
  61 .. _howto_churn:
  62
  63 Modeling Churn (e.g. in P2P)
  64 ****************************
  65
  66 One of the biggest challenges in P2P settings is to cope with the
  67 churn, meaning that resources keep appearing and disappearing. In
  68 SimGrid, you can always change the state of each host manually, with
  69 eg :cpp:func:`simgrid::s4u::Host::turn_on`. To reduce the burden when
  70 the churn is high, you can also attach a **state profile** to the host
  71 directly.
  72
  73 This can be done through the XML file, using the ``state_file``
  74 attribute of :ref:`pf_tag_host`, :ref:`pf_tag_cluster` or
  75 :ref:`pf_tag_link`. Every lines (but the last) of such files describe
  76 timed events with the form "date value". Example:
  77
  78 .. code-block:: python
  79
  80    1 0
  81    2 1
  82    LOOPAFTER 8
  83
  84 - At time t=1, the host is turned off (value 0 means OFF)
  85 - At time t=2, it is turned back on (other values means ON)
  86 - At time t=10, the history is reset (because that's 8 seconds after
  87   the last event). So the host will be turned off again at t=11.
  88
  89 If your trace does not contain a LOOPAFTER line, then your profile is
  90 only executed once and not repetitively.
  91
  92 Another possibility is to use the
  93 :cpp:func:`simgrid::s4u::Host::set_state_profile()` or
  94 :cpp:func:`simgrid::s4u::Link::set_state_profile()` functions. These
  95 functions take a profile, that can be an fixed profile exhaustively
  96 listing the events, or something else if you wish.
  97
  98 .. _howto_multicore:
  99
 100 Modeling Multicore Machines
 101 ***************************
 102
 103 Default Model
 104 =============
 105
 106 Multicore machines are very complex, and there is many way to model
 107 them. The default models of SimGrid are coarse grain and capture some
 108 elements of this reality. Here is how to declare simple multicore hosts:
 109
 110 .. code-block:: xml
 111
 112    <host id="mymachine" speed="8Gf" core="4"/>
 113
 114 It declares a 4-cores host called "mymachine", each core computing 8
 115 GFlops per second. If you put one activity of 8 GFlop on this host, it
 116 will be computed in 1 second (by default, activities are
 117 single-threaded and cannot leverage the computing power of more than
 118 one core). If you put two of them together, they will still be
 119 computed in one second, and so on up to 4 tasks. If you put 5 tasks,
 120 they will share the total computing resource, and all tasks will be
 121 computed at 5/4 = 1.25 second. That's a very simple model, but that's
 122 all what you will get by default from SimGrid.
 123
 124 Pinning tasks to cores
 125 ======================
 126
 127 The default model does not account for task pinning, where you
 128 manually select on which core each of the existing activity should
 129 execute. The best solution to model this is probably to model your
 130 4-core processor as 4 separte hosts, and assigning the activities to
 131 cores by migrating them to the declared hosts. In some sense, this
 132 takes the whole Network-On-Chip idea really seriously.
 133
 134 Some extra complications may arise here. If you have more tasks than
 135 cores, you'll have to `schedule your tasks
 136 <https://en.wikipedia.org/wiki/Scheduling_%28computing%29#Operating_system_process_scheduler_implementations)>`_
 137 yourself on the cores (so you'd better avoid this complexity). Since
 138 you cannot have more than one network model in a given SimGrid
 139 simulation, you will end up with a TCP connexion between your cores. A
 140 possible work around is to never start any simulated communication
 141 between the cores and have the same routes from each core to the
 142 rest of the external network.
 143
 144 Modeling a multicore CPU as a set of SimGrid hosts may seem strange
 145 and unconvincing, but some users achieved very realistic simulations
 146 of multi-core and GPU machines this way.
 147
 148 Modeling machine bootup and shutdown periods
 149 ********************************************
 150
 151 When a physical host boots up, a lot of things happen. It takes time
 152 during which the machine is not usable but dissipates energy, and
 153 programs actually die and restart during a reboot. Since there is many
 154 ways to model it, SimGrid does not do any modeling choice for you but
 155 the most obvious ones.
 156
 157 Any actor (or process in MSG) running on an host that is shut down
 158 will be killed and all its activities (tasks in MSG) will be
 159 automatically canceled. If killed the actor was marked as
 160 auto-restartable (with
 161 :cpp:func:`simgrid::s4u::Actor::set_auto_restart` or with
 162 :cpp:func:`MSG_process_auto_restart_set`), it will start anew with the
 163 same parameters when the host boots back up.
 164
 165 By default, shutdowns and bootups are instantaneous. If you want to
 166 add an extra delay, you have to do that yourself, for example from an
 167 `controler` actor that runs on another host. The best way to do so is
 168 to declare a fictionous pstate where the CPU delivers 0 flop per
 169 second (so every activity on that host will be frozen when the host is
 170 in this pstate). When you want to switch the host off, your controler
 171 switches the host to that specific pstate (with
 172 :cpp:func:`simgrid::s4u::Host::set_pstate`), waits for the amount of
 173 time that you decided necessary for your host to shut down, and turns
 174 the host off (with :cpp:func:`simgrid::s4u::Host::turn_off`). To boot
 175 up, switch the host on, go into the specific pstate, wait a while and
 176 go to a more regular pstate.
 177
 178 To model the energy dissipation, you need to put the right energy
 179 consumption in your startup/shutdown specific pstate. Remember that
 180 the energy consumed is equal to the instantaneous consumption
 181 multiplied by the time in which the host keeps in that state. Do the
 182 maths, and set the right instantaneous consumption to your pstate, and
 183 you'll get the whole boot period to consume the amount of energy that
 184 you want. You may want to have one fictionous pstate for the bootup
 185 period and another one for the shutdown period.
 186
 187 Of course, this is only one possible way to model these things. YMMV ;)
 188