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