@@ -16,21 +16,22 @@ In Batmen, we added a layer: **the simulation of users**.
The interaction with users happens through a "broker". The broker manages a pool of simulated users and dynamically register new jobs to sumbit. These jobs come on top of the input workload read by Batsim.
Implementation, in the folder `src/users`:
-*dynscheduler*: superclass managing the interaction with the broker from which the scheduling algorithms inherit
-*broker*: implement the broker itself, submitting the jobs on behalf of the users
-*broker*: implement the broker, submitting the jobs on behalf of the users
-*dynscheduler*: superclass managing the interaction with the broker from the scheduler
-*user*: an individual user, submitting her jobs to the broker
### Types of user
TBD
- feedback users
- replay users
- modelled users
### Available schedulers
Dynamic submission is supported by all the schedulers inheriting from the class `DynScheduler` i.e., all the schedulers located in the folder `src/scheds`. Some of them support machines with more than one core while others are only for monocore machines.
Dynamic submission is supported by all the schedulers inheriting from the class `DynScheduler` i.e., all the schedulers located in the folder `src/scheds`. Some of them support multicore machines while others only support monocore machines.
- monocore schedulers:
-*fcfs*:
-*easy-bf*:
-*fcfs*: TBD
-*easy-bf*: TBD
- multicore schedulers:
-*bin_packing*: the scheduler packs the jobs on the least number of multicore machines. Each job runs on only one host but can take several cores
-*bin_packing_energy*: same as *bin_packing*, but saves power by switching off the machines as soon as they are idle and powering them on again when needed