[x] Some of the text is a bit too basic such as "while making the processes as happy as possible". Maybe it could replaced by "running the processes as fast as possible".
[x] maybe introduce some scheduling goals such as minimizing makespan.
[x] I would separate the coordinator-worker problem from the underlying infrastructure where it runs on. So no mixing of (shared) links between workers and coordinators or any infrastructure information in the first phase. Maybe couple with a more detailed phase towards the end that exposes where these workers and coordinator can run, and that the underlying infrastructure has an impact on optimization goals (makespan, costs, etc.).
[x] try to avoid too much terminology. e.g. i would eliminate processes and uses only tasks instead.
[x] maybe introduce the term task earlier and explain that it can have input and output data - without exposing and infrastructure information
[x] I would delay any implementation details to the end of the module description - such as "In practice, we would implement step c) ..." It is difficult enough to understand the concept. Let's dont make it too complex by combining it with implementation or infrastructure details this early in the explanation.
[x] Maybe under the list of what to do for a) and b) also include: pick the worker that has least work to do.
Simulation sw:
[x] For the worker/coordinator view, I would also allow to select how many worker one can use. students should understand that it makes a difference whether I have 1, 2, 4, ... workers available (Henri: I don't think Thomas looked at the second tab)
[x] It would be nice to see multiple experimental results side by side to allow for comparison of different configurations; instead of deleting previous experiments;
[x] It would be nice to have some random generator for nr of workers and tasks with some upper or lower bound values.
Regarding the examples:
[x] Maybe also let them do an example that shows by increasing workers, the makespan can reduce until a certain number of workers and then it may actually increase. Students should get a feeling that using the maximum number of workers may not always deliver best results. Henri: this is done in [A.3.3.p1.6]
[x] Some of the text is a bit too basic such as "while making the processes as happy as possible". Maybe it could replaced by "running the processes as fast as possible".
[x] maybe introduce some scheduling goals such as minimizing makespan.
[x] I would separate the coordinator-worker problem from the underlying infrastructure where it runs on. So no mixing of (shared) links between workers and coordinators or any infrastructure information in the first phase. Maybe couple with a more detailed phase towards the end that exposes where these workers and coordinator can run, and that the underlying infrastructure has an impact on optimization goals (makespan, costs, etc.).
[x] try to avoid too much terminology. e.g. i would eliminate processes and uses only tasks instead.
[x] maybe introduce the term task earlier and explain that it can have input and output data - without exposing and infrastructure information
[x] I would delay any implementation details to the end of the module description - such as "In practice, we would implement step c) ..." It is difficult enough to understand the concept. Let's dont make it too complex by combining it with implementation or infrastructure details this early in the explanation.
[x] Maybe under the list of what to do for a) and b) also include: pick the worker that has least work to do.
Simulation sw:
Regarding the examples:
[x] Maybe also let them do an example that shows by increasing workers, the makespan can reduce until a certain number of workers and then it may actually increase. Students should get a feeling that using the maximum number of workers may not always deliver best results. Henri: this is done in [A.3.3.p1.6]