doc/doxygen/howtos.doc

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