Elektron is a lightweight, power-aware, pluggable Mesos framework that behaves as a playground to experiment with different scheduling policies to schedule ad-hoc jobs in docker containers.
This repository has been archived on 2024-04-10. You can view files and clone it, but you cannot make any changes to it's state, such as pushing and creating new issues, pull requests or comments.
Find a file
2017-02-20 22:42:07 -05:00
constants added a constant called CapThreshold that defines the lower limit below which we shouldn't cap a node. 2017-02-15 19:15:18 -05:00
def Made classMapWatts a commandLine option where one can enable and disable mapping of watts to powerclasses when accepting offers from Mesos. Removed the schedulers that were created solely for the classMapWatts feature. Retrofitted all schedulers to use the powerClass mapped watts attribute for a task, if classMapWatts has been enabled. Removed unnecessary functions and variables from constants.go. Removed unnecessary functions from utilities/utils.go. Fixed operator precendence issue with takeOffer(...) in some of the schedulers. Added TODO to decouple capping strategies from the schedulers completely. Added TODO to move all the common struct attributes in the schedulers into base.go. 2017-02-09 18:05:38 -05:00
pcp Fixed corner cases in progressive extrema -- When a node is capped and the new cap value is above a threshold then that node can be capped or uncapped in the next cycle. If the new cap value is equal to the threshold then the node cannot be capped further and can only be uncapped. When the node is uncapped and the newUncapValue is below 100 then the node can be capped or uncapped in the next cycle. If the newUncapValue is 100 then the node can only be capped. 2017-02-20 20:55:06 -05:00
powerCapping resolved merge conflict with master. Also, changed the name of the constructor for BPSWMaxMin from NewBPMaxMinWatts to NewBPSWMaxMinWatts 2017-02-11 14:26:27 -05:00
rapl changed the type of percentage in rapl.Cap(...) from int to float64. Retrofitted power-capping strategies to cap using a float64 value instead of an int. Moved common functions in loganddynamiccap.go and logAndProgressiveExtrema.go into pcp/utils.go. New power-capping strategy that builds on top of extrema, where it caps the victims at different until it can't cap further, in which case it starts uncapping them in the reverse order of capping. 2017-02-15 19:22:56 -05:00
schedulers removed TODO for consolidating common scheduler struct members into base.go. 2017-02-20 22:42:07 -05:00
utilities formatted files 2017-02-11 00:05:42 -05:00
config basic configuration for pcp 2016-12-22 22:58:58 -05:00
README.md Added TODO for making WattsToConsider(...) a receiver of def.Task and changing its name to Watts(...) 2017-02-10 20:28:06 -05:00
scheduler.go Fixed corner cases in progressive extrema -- When a node is capped and the new cap value is above a threshold then that node can be capped or uncapped in the next cycle. If the new cap value is equal to the threshold then the node cannot be capped further and can only be uncapped. When the node is uncapped and the newUncapValue is below 100 then the node can be capped or uncapped in the next cycle. If the newUncapValue is 100 then the node can only be capped. 2017-02-20 20:55:06 -05:00
workload_sample.json Adding node class mapping for Watts as a resource in binpack 2016-12-23 21:04:15 -05:00

Electron: A power budget manager

To Do:

  • Create metrics for each task launched [Time to schedule, run time, power used]
  • Have calibration phase?
  • Add ability to use constraints
  • Running average calculations https://en.wikipedia.org/wiki/Moving_average#Exponential_moving_average
  • Make parameters corresponding to each scheduler configurable (possible to have a config template for each scheduler?)
  • TODO : Adding type of scheduler to be used, to be picked from a config file, along with it's configurable parameters.
  • Write test code for each scheduler (This should be after the design change)
  • Some of the constants in constants/constants.go can vary based on the environment.
    Possible to setup the constants at runtime based on the environment?
  • Log fix for declining offer -- different reason when insufficient resources as compared to when there are no longer any tasks to schedule.
  • Have a centralised logFile that can be filtered by identifier. All electron logs should go into this file.
  • Make def.Task an interface for further modularization and flexibility.
  • Convert def#WattsToConsider(...) to be a receiver of def.Task and change the name of it to Watts(...).

Requires Performance Co-Pilot tool pmdumptext to be installed on the machine on which electron is launched for logging to work and PCP collector agents installed on the Mesos Agents

How to run (Use the --help option to get information about other command-line options):

./electron -workload <workload json>

To run electron with ignoreWatts, run the following command,

./electron -workload <workload json> -ignoreWatts

Workload schema:

[
   {
      "name": "minife",
      "cpu": 3.0,
      "ram": 4096,
      "watts": 50,
      "image": "gouravr/minife:v5",
      "cmd": "cd src && mpirun -np 1 miniFE.x -nx 100 -ny 100 -nz 100",
      "inst": 9,
      "class_to_watts" : {
          "A": 30.2475289996,
          "B": 35.6491229228,
          "C": 24.0476734352
       }

   },
   {
      "name": "dgemm",
      "cpu": 3.0,
      "ram": 4096,
      "watts": 50,
      "image": "gouravr/dgemm:v2",
      "cmd": "/./mt-dgemm 1024",
      "inst": 9,
      "class_to_watts" : {
          "A": 35.2475289996,
          "B": 25.6491229228,
          "C": 29.0476734352
       }
   }
]