+Lab 3: Fixed Experiment Duration
+--------------------------------
+
+In the current version, the number of tasks is defined through the
+worker arguments. Hence, tasks are created at the very beginning of
+the simulation. Instead, have the master dispatching tasks for a
+predetermined amount of time. The tasks must now be created on demand
+instead of beforehand.
+
+Of course, usual time functions like ``gettimeofday`` will give you the
+time on your real machine, which is prety useless in the
+simulation. Instead, retrieve the time in the simulated world with
+:cpp:func:`simgrid::s4u::Engine::get_clock`.
+
+You can still stop your workers with a specific task as previously,
+or you may kill them forcefully with
+:cpp:func:`simgrid::s4u::Actor::kill` (if you already have a reference
+to the actor you want to kill) or
+:cpp:func:`void simgrid::s4u::Actor::kill(aid_t)` (if you only have its ID).
+
+
+Anyway, the new deployment `deployment3.xml` file should thus look
+like this:
+
+.. literalinclude:: tuto_s4u/deployment3.xml
+ :language: xml
+
+Controlling the message verbosity
+.................................
+
+Not all messages are equally informative, so you probably want to
+change some of the ``XBT_INFO`` into ``XBT_DEBUG`` so that they are
+hidden by default. For example, you may want to use ``XBT_INFO`` once
+every 100 tasks and ``XBT_DEBUG`` when sending all the other tasks. Or
+you could show only the total number of tasks processed by
+default. You can still see the debug messages as follows:
+
+.. code-block:: shell
+
+ ./master-workers-lab3 small_platform.xml deployment3.xml --log=msg_test.thres:debug
+
+
+Lab 4: Competing Applications
+-----------------------------
+
+It is now time to start several applications at once, with the following ``deployment4.xml`` file.
+
+.. literalinclude:: tuto_s4u/deployment4.xml
+ :language: xml
+
+Things happen when you do so, but it remains utterly difficult to
+understand what's happening exactely. Even Gantt visualizations
+contain too much information to be useful: it is impossible to
+understand which task belong to which application. To fix this, we
+will categorize the tasks.
+
+Instead of starting the execution in one function call only with
+``this_actor::execute(cost)``, you need to
+create the execution activity, set its tracing category, and then start
+it and wait for its completion, as follows:
+
+.. code-block:: cpp
+
+ simgrid::s4u::ExecPtr exec = simgrid::s4u::this_actor::exec_init(compute_cost);
+ exec->set_tracing_category(category);
+ // exec->start() is optional here as wait() starts the activity on need
+ exec->wait();
+
+You can make the same code shorter as follows:
+
+.. code-block:: cpp
+
+ simgrid::s4u::this_actor::exec_init(compute_cost)->set_tracing_category(category)->wait();
+
+Visualizing the result
+.......................
+
+vite is not enough to understand the situation, because it does not
+deal with categorization. This time, you absolutely must switch to R,
+as explained on `this page
+<http://simgrid.gforge.inria.fr/contrib/R_visualization.php>`_.
+
+.. todo::
+
+ Include here the minimal setting to view something in R.
+
+
+Lab 5: Better Scheduling
+------------------------
+
+You don't need a very advanced visualization solution to notice that
+round-robin is completely suboptimal: most of the workers keep waiting
+for more work. We will move to a First-Come First-Served mechanism
+instead.
+
+For that, your workers should explicitely request for work with a
+message sent to a channel that is specific to their master. The name
+of that private channel can be the one used to categorize the
+executions, as it is already specific to each master.
+
+The master should serve in a round-robin manner the requests it
+receives, until the time is up. Changing the communication schema can
+be a bit hairy, but once it works, you will see that such as simple
+FCFS schema allows to double the amount of tasks handled over time
+here. Things may be different with another platform file.
+
+Further Improvements
+....................
+
+From this, many things can easily be added. For example, you could:
+
+- Allow workers to have several pending requests so as to overlap
+ communication and computations as much as possible. Non-blocking
+ communication will probably become handy here.
+- Add a performance measurement mechanism, enabling the master to make smart scheduling choices.
+- Test your code on other platforms, from the ``examples/platforms``
+ directory in your archive.
+
+ What is the largest number of tasks requiring 50e6 flops and 1e5
+ bytes that you manage to distribute and process in one hour on
+ ``g5k.xml`` ?
+- Optimize not only for the amount of tasks handled, but also for the
+ total energy dissipated.
+- And so on. If you come up with a really nice extension, please share
+ it with us so that we can extend this tutorial.
+
+After this Tutorial
+-------------------
+
+This tutorial is now terminated. You could keep reading the [online documentation][fn:4] or
+[tutorials][fn:7], or you could head up to the example section to read some code.
+
+.. todo::
+
+ TODO: Points to improve for the next time
+
+ - Propose equivalent exercises and skeleton in java.
+ - Propose a virtualbox image with everything (simgrid, pajeng, ...) already set up.
+ - Ease the installation on mac OS X (binary installer) and windows.