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_multicore How to model multicore machines
  22
  23 Multicore machines are very complex, and there is many way to model
  24 them. The default models of SimGrid are coarse grain and capture some
  25 elements of this reality. Here is how to declare simple multicore hosts:
  26
  27 @code{xml}
  28  <host id="mymachine" speed="8Gf" core="4"/>
  29 @endcode
  30
  31 It declares a 4-cores host called "mymachine", each core computing 8
  32 GFlops per second. If you put one activity of 8 GFlop on this host, it
  33 will be computed in 1 second (by default, activities are
  34 single-threaded and cannot leverage the computing power of more than
  35 one core). If you put two of them together, they will still be
  36 computed in one second, and so on up to 4 tasks. If you put 5 tasks,
  37 they will share the total computing resource, and all tasks will be
  38 computed at 5/4 = 1.25 second. That's a very simple model, but that's
  39 all what you will get by default from SimGrid.
  40
  41 @subsection howto_multicore_pinning Pinning tasks to cores
  42
  43 This model does not account for any sort of resource reservation such
  44 as task pinning (where you manually select on which core each of the
  45 existing activity should execute). If you want to go that way, the
  46 best is probably to model you 4-core processor as 4 separte hosts, and
  47 assigning the activities to cores by migrating them to the declared
  48 hosts. In some sense, this is takes the whole Network-On-Chip idea
  49 really seriously.
  50
  51 Some extra complications may arise if you go that way. If you have
  52 more tasks than cores, you'll have to [schedule your
  53 tasks](https://en.wikipedia.org/wiki/Scheduling_%28computing%29#Operating_system_process_scheduler_implementations)
  54 yourself on the cores (so don't do that if you can avoid). Since you
  55 cannot have more than one network model, you will end up with a TCP
  56 connexion between your cores. You probably want to work this around in
  57 your application by never starting any simulated communication between
  58 your cores. Instead, connect equally all cores to the external
  59 network.
  60
  61 Modeling a multicore CPU as a set of SimGrid hosts may seem strange
  62 and unconvincing, but some users achieved very realistic simulations
  63 of multi-core and GPU machines this way.
  64
  65 @section howto_bootenergy Modeling machine bootup and shutdown periods
  66
  67 When a physical host boots up, a lot of things happen. It takes time
  68 during which the machine is not usable but dissipates energy, and
  69 programs actually die and restart during a reboot. Since there is many
  70 ways to model it, SimGrid does not do any modeling choice for you but
  71 the most obvious ones.
  72
  73 Any actor (or process in MSG) running on an host that is shut down
  74 will be killed and all its activities (tasks in MSG) will be
  75 automatically canceled. If killed the actor was marked as
  76 auto-restartable (with simgrid::s4u::Actor::setAutoRestart() or with
  77 MSG_process_auto_restart_set()), it will start anew with the same
  78 parameters when the host boots back up.
  79
  80 By default, shutdowns and bootups are instantaneous. If you want to
  81 add an extra delay, you have to do that yourself, for example from an
  82 /controler/ actor that runs on another host. The best way to do so is
  83 to declare a fictionous pstate where the CPU delivers 0 flop per
  84 second (so every activity on that host will be frozen when the host is
  85 in this pstate). When you want to switch the host off, your controler
  86 switches the host to that specific pstate (with
  87 simgrid::s4u::Host::setPstate()), waits for the amount of time that
  88 you decided necessary for your host to shut down, and turns the host
  89 off (with simgrid::s4u::Host::turnOff()). To boot up, switch the host
  90 on, go into the specific pstate, wait a while and go to a more regular
  91 pstate.
  92
  93 To model the energy dissipation, you need to put the right energy
  94 consumption in your startup/shutdown specific pstate. Remember that
  95 the energy consumed is equal to the instantaneous consumption
  96 multiplied by the time in which the host keeps in that state. Do the
  97 maths, and set the right instantaneous consumption to your pstate, and
  98 you'll get the whole boot period to consume the amount of energy that
  99 you want. You may want to have one fictionous pstate for the bootup
 100 period and another one for the shutdown period.
 101
 102 Of course, this is only one possible way to model these things. YMMV ;)
 103
 104 */