1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
/** @page howto Use Cases and Howtos
@tableofcontents
There is no perfect model, but only models that are adapted to the
specific study that you want to do. SimGrid provide several advanced
mechanisms that you can adapt to model the situation that you are
interested into, and it is often uneasy to see where to start with.
This page collects several hints and tricks on modeling situations.
Most probably, the exact situation that you want to model will not be
described here (unless we already [scooped
you](http://www.phdcomics.com/comics/archive.php?comicid=789)), but we
hope you will find some ideas and see how to use the modeling options
that SimGrid provides.
Of course, you should also check the @ref examples page, that shows
more detailed usage examples. As for the rest of the documentation
(and of SimGrid, actually), any contribution is welcome.
@section howto_churn How to model churn
One of the biggest challenges in P2P settings is to cope with the
churn, meaning that resources keep appearing and disappearing. In
SimGrid, you can always change the state of each host manually, with
eg simgrid::s4u::Host::on(). To reduce the burden when the churn is
high, you can also attach a **state profile** to the host directly.
This is not possible from S4U yet (TODO), and you should use the \c
state_file attribute of @ref pf_tag_host or @ref pf_tag_cluster.
Every lines (but the last) of such files describe timed events with
the form "date value". Example:
~~~{.py}
1 0
2 1
LOOPAFTER 8
~~~
- At time t=1, the host is turned off (value 0 means OFF)
- At time t=2, it is turned back on (other values means ON)
- At time t=10, the history is reset (because that's 8 seconds after
the last event). So the host will be turned off again at t=11.
If your trace does not contain a LOOPAFTER line, then your profile is
only executed once and not repetitively.
@section howto_multicore How to model multicore machines
Multicore machines are very complex, and there is many way to model
them. The default models of SimGrid are coarse grain and capture some
elements of this reality. Here is how to declare simple multicore hosts:
@code{xml}
<host id="mymachine" speed="8Gf" core="4"/>
@endcode
It declares a 4-cores host called "mymachine", each core computing 8
GFlops per second. If you put one activity of 8 GFlop on this host, it
will be computed in 1 second (by default, activities are
single-threaded and cannot leverage the computing power of more than
one core). If you put two of them together, they will still be
computed in one second, and so on up to 4 tasks. If you put 5 tasks,
they will share the total computing resource, and all tasks will be
computed at 5/4 = 1.25 second. That's a very simple model, but that's
all what you will get by default from SimGrid.
@subsection howto_multicore_pinning Pinning tasks to cores
This model does not account for any sort of resource reservation such
as task pinning (where you manually select on which core each of the
existing activity should execute). If you want to go that way, the
best is probably to model you 4-core processor as 4 separte hosts, and
assigning the activities to cores by migrating them to the declared
hosts. In some sense, this is takes the whole Network-On-Chip idea
really seriously.
Some extra complications may arise if you go that way. If you have
more tasks than cores, you'll have to [schedule your
tasks](https://en.wikipedia.org/wiki/Scheduling_%28computing%29#Operating_system_process_scheduler_implementations)
yourself on the cores (so don't do that if you can avoid). Since you
cannot have more than one network model, you will end up with a TCP
connexion between your cores. You probably want to work this around in
your application by never starting any simulated communication between
your cores. Instead, connect equally all cores to the external
network.
Modeling a multicore CPU as a set of SimGrid hosts may seem strange
and unconvincing, but some users achieved very realistic simulations
of multi-core and GPU machines this way.
@section howto_bootenergy Modeling machine bootup and shutdown periods
When a physical host boots up, a lot of things happen. It takes time
during which the machine is not usable but dissipates energy, and
programs actually die and restart during a reboot. Since there is many
ways to model it, SimGrid does not do any modeling choice for you but
the most obvious ones.
Any actor (or process in MSG) running on an host that is shut down
will be killed and all its activities (tasks in MSG) will be
automatically canceled. If killed the actor was marked as
auto-restartable (with simgrid::s4u::Actor::setAutoRestart() or with
MSG_process_auto_restart_set()), it will start anew with the same
parameters when the host boots back up.
By default, shutdowns and bootups are instantaneous. If you want to
add an extra delay, you have to do that yourself, for example from an
/controler/ actor that runs on another host. The best way to do so is
to declare a fictionous pstate where the CPU delivers 0 flop per
second (so every activity on that host will be frozen when the host is
in this pstate). When you want to switch the host off, your controler
switches the host to that specific pstate (with
simgrid::s4u::Host::setPstate()), waits for the amount of time that
you decided necessary for your host to shut down, and turns the host
off (with simgrid::s4u::Host::turnOff()). To boot up, switch the host
on, go into the specific pstate, wait a while and go to a more regular
pstate.
To model the energy dissipation, you need to put the right energy
consumption in your startup/shutdown specific pstate. Remember that
the energy consumed is equal to the instantaneous consumption
multiplied by the time in which the host keeps in that state. Do the
maths, and set the right instantaneous consumption to your pstate, and
you'll get the whole boot period to consume the amount of energy that
you want. You may want to have one fictionous pstate for the bootup
period and another one for the shutdown period.
Of course, this is only one possible way to model these things. YMMV ;)
*/
|
