Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
pass on examples
[simgrid.git] / 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 a 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