/
External Interface Design for Power Awareness.

External Interface Design for Power Awareness.

Apr 23, 2020

Technical Term

Description or Definition

PMI

Power Management Infrastructure

 

Tractability Matrix

Use Case(s)

Requirement(s)

Interface(s)

Use Case(s)

Requirement(s)

Interface(s)

2.a

3.a, 3.b, 3.e, 3.f

2, 10, 11

2.b

3.d, 3.g

1, 4, 6, 7, 8, 9, 12, 24-38, 40-49

2.c

3.c

3, 5, 13, 18, 20, 21, 39

 

A. Interface changes

  1. Interface #1

    1. Visibility: Public

    2. Change Control: Stable

    3. Synopsis: Generically applicable server power_provisioning  flag

    4. Reference to more detail on the interface.

      1. The  power_provisioning boolean server attribute will have a default of unset, be visible to all and changeable by a manager.  When it is set True, PMI operations may take place if allowed by vnode power_provisioning flag (see A.1.9).  If it is unset or set False, no PMI operations will take place on any vnode.

      2. Use qmgr to set the power_provisioning flag true or false.  For example:   

  2. Interface #2

    1. Visibility: Public

    2. Change Control: Stable

    3. Synopsis: Generically applicable energy usage for a job

      1. Add a new attribute for a job: resources_used.energy

    4. Reference to more detail on the interface.

      1. The type will be float.

      2. The units will be kWh.  For example:  resources_used.energy=64.2

      3. The resources_used.energy value will only be updated when PMI operations are allowed on the vnodes used by the job. The resources_used.energy value will not be seen in qstat -f output or server/accounting logs when PMI operations are not allowed on the node.

  3. Interface #3

    1. Visibility: Public

    2. Change Control: Stable

    3. Synopsis: Generically applicable resource “eoe”

      1. A new resource similar to “aoe” is added to both jobs and vnodes to specify the energy operational environment.

    4. Reference to more detail on the interface.

      1. Is added to default resource list of scheduler in sched_config file.

      2. It is a non-consumable resource.

      3. It is of type resource, added to attribute resources_available. e.g. resources_available.eoe=”low,med,high”. It is a string array.

      4. Contains list of all power profile names that are available on a vnode. By default, resources_available.eoe is unset.

      5. The list is visible to all but settable only by manager.

      6. Job Resource_List.eoe per chunk in –l select as –l select=1:ncpus:eoe=low. This will request one chunk from a node with resource_available.eoe=low.

      7. Only one eoe value can be active on a vnode at a time.

      8. A job Resource_List.eoe may be requested in a select statement but no more than one distinct value for the requested eoe is currently supported. i.e. -lselect=1:ncpus=1:eoe=med+1:ncpus=2:eoe=med

      9. If a Job request is made with more than one value for eoe (I.e. –l select=1:eoe=low+1:eoe=high), it will be rejected by qsub with the error “qsub: only one value of eoe is allowed”.

      10. A value for resources_available.eoe will not be automatically set on the system(s) where the PBS server and scheduler are running.

      11. If both an aoe and eoe are set for a job, the aoe setting will be processed first by the scheduler.

      12. The scheduler will not preempt a job with eoe set using suspend or checkpoint.

  4. Interface #4

    1. Visibility: Public

    2. Change Control: Stable

    3. Synopsis: Generically applicable vnode attribute: current_eoe

    4. Reference to more detail on the interface.

      1. Identifies the eoe active on a vnode. It is of type String. By default, it is unset. It is settable only by manager and visible to all.

      2. A job J1 running with a eoe setting X will cause the value of current_eoe to be set  to X on the vnodes assigned to J1 that allow PMI operations.

      3. Manually changing current_eoe is unsupported.

      4. The scheduler can run a job requesting an eoe on vnodes with a current_eoe value that matches the job eoe.

      5. The scheduler can only run a job on a vnode where the current_eoe does not match the job eoe if no jobs are running on the vnode and PMI operations are allowed on the vnode.

      6. When a job ends the deactivate operation will take place if all the vnodes used by the job have no other jobs running and allow PMI operations.  At this point, current_eoe will be unset on all the vnodes used by the job.

  5. Interface #5

    1. Visibility: Public

    2. Change Control: Stable

    3. Synopsis: Cray specific resource: pstate

    4. Reference to more detail on the interface.

      1. Cray ALPS reservation setting for p-state.  See Basil 1.4 documentation.

      2. It is of type String. By default, it is unset. It is settable and visible to all PBS users.

  6. Interface #6

    1. Visibility: Public

    2. Change Control: Stable

    3. Synopsis: Cray specific resource: pgov

    4. Reference to more detail on the interface.

      1. Cray ALPS reservation setting for p-governor.  See Basil 1.4 documentation.

      2. It is of type String. By default, it is unset. It is settable and visible to all PBS users.

  7. Interface #7

    1. Visibility: Public

    2. Change Control: Stable

    3. Synopsis: Cray specific resource: pcap_node

    4. Reference to more detail on the interface.

      1. Cray capmc set_power_cap --node setting.  See capmc documentation.

      2. It is of type Int. By default, it is unset. It is settable and visible to all PBS users.

      3. A  negative value will result in a PBSE_BADATVAL error.

  8. Interface #8

    1. Visibility: Public

    2. Change Control: Stable

    3. Synopsis: Cray specific resource: pcap_accelerator

    4. Reference to more detail on the interface.

      1. Cray capmc set_power_cap --accel setting.  See capmc documentation.

      2. It is of type Int. By default, it is unset. It is settable and visible to all PBS users.

      3. A negative value will result in a PBSE_BADATVAL error.

  9. Interface #9

    1. Visibility: Public

    2. Change Control: Stable

    3. Synopsis: Generically applicable vnode power_provisioning flag

    4. Reference to more detail on the interface.

      1. The  power_provisioning boolean vnode attribute will be unset by default, be visible to all and changeable by a manager.

      2. Use qmgr to set the power_provisioning flag true or false.  For example:

      3. When it is set to True, PMI operations may take place on the vnode.  If it is unset or set to False, no PMI operations are allowed to take place on the vnode.

  10. Interface #10

    1. Visibility: Public

    2. Change Control: Stable

    3. Synopsis: Mom log using logjobmsg when a job ends and the value of current_eoe is unset.

    4. Reference to more detail on the interface.

      1. Example:

  11. Interface #11

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: When the energy for a job on an SGI HPE system is obtained, it will be logged by MoM using logjobmsg.

    4. Reference to more detail on the interface.

      1. Example:

  12. Interface #12

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: The Cray capmc command invocations will be logged by MoM using LOG_DEBUG with the keyword “launch”.

    4. Reference to more detail on the interface.

      1. Example:

  13. Interface #13

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis:  Following a successful Cray capmc invocation, a message will be logged by MoM using LOG_WARNING if the time used by capmc is greater than 30 seconds.

    4. Reference to more detail on the interface.

      1. Example:

  14. Interface #14

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis:  If Cray capmc writes anything to stderr, the first line will be logged by MoM using LOG_WARNING after the “launch” message.

    4. Reference to more detail on the interface.

      1. Cray has not documented the possible stderr output from capmc.

      2. Example:

  15. Interface #15

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis:  When Cray capmc is run with the argument “get_node_energy_counter”, the node count is checked and if it is wrong, a message will be logged by MoM using logjobmsg.

    4. Reference to more detail on the interface.

      1. The same command will be run one additional time if an error is seen.  No message will be logged for the first error.  If an error occurs after the second attempt, a message is logged.

      2. For example:

      3. The output from capmc should include a node count.  If it does not, the messages will show “not set” instead of a number.

      4. Example:

  16. Interface #16

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: If Cray RUR is configured (see B.1.f), log messages will be logged by MoM using logjobmsg when a job ends.

    4. Reference to more detail on the interface.

      1. A message will show the energy used by each aprun run by a job and a job tally in Joules.  For example:

  17. Interface #17

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: If Cray RUR is not configured, a log message will be logged by MoM using logjobmsg when a job ends.

    4. Reference to more detail on the interface.

      1. Example:

  18. Interface #18

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: At the end of a job on a Cray, the energy reported by capmc for the compute nodes used by the job will be logged  by MoM using logjobmsg.

    4. Reference to more detail on the interface.

      1. Example:

  19. Interface #19

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: The energy reported by capmc for the compute nodes used by a job on a Cray will be logged by MoM using logjobmsg periodically every 5 minutes as the job runs.

    4. Reference to more detail on the interface.

      1. Example:

  20. Interface #20

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: When the PMI on a Cray is initialized, MoM will log messages at LOG_DEBUG.

    4. Reference to more detail on the interface.

      1. Example:

  21. Interface #21

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: When get_usage() is called for a job on a Cray, a message will be logged by MoM using logjobmsg.

    4. Reference to more detail on the interface.

      1. Example:

  22. Interface #22

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: When query() is called on a Cray, a message will be logged by MoM using LOG_DEBUG.

    4. Reference to more detail on the interface.

      1. Example:

  23. Interface #23

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: When activate_profile() is called on a Cray, a message will be logged by MoM using LOG_DEBUG.

    4. Reference to more detail on the interface.

      1. Example:

  24. Interface #24

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: When activate_profile() is called on a Cray but no compute nodes are allocated to the job, a message will be logged by MoM using logjobmsg.

    4. Reference to more detail on the interface.

      1. Example:

  25. Interface #25

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: When activate_profile() is called on a Cray and the job has pcap_node set, a message will be logged by MoM using logjobmsg showing the pcap_node value.

    4. Reference to more detail on the interface.

      1. Example:

  26. Interface #26

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: When activate_profile() is called on a Cray and the job has pcap_accelerator set, a message will be logged by MoM using logjobmsg showing the pcap_ accelerator value.

    4. Reference to more detail on the interface.

      1. Example:

  27. Interface #27

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: When activate_profile() is called on a Cray and the job has neither pcap_node or pcap_accelerator set, a message will be logged by MoM using logjobmsg.

    4. Reference to more detail on the interface.

      1. Example:

  28. Interface #28

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: When deactivate_profile() is called on a Cray, a message will be logged by MoM using LOG_DEBUG.

    4. Reference to more detail on the interface.

      1. Example:

  29. Interface #29

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: When deactivate_profile() is called on a Cray but no compute nodes are allocated to the job, a message will be logged by MoM using logjobmsg.

    4. Reference to more detail on the interface.

      1. Example:

  30. Interface #30

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: When deactivate_profile() is called on a Cray and the job has pcap_node set, a message will be logged by MoM using logjobmsg showing the pcap_node value.

    4. Reference to more detail on the interface.

      1. Example:

  31. Interface #31

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: When deactivate_profile() is called on a Cray and the job has pcap_accelerator set, a message will be logged by MoM using logjobmsg showing the pcap_ accelerator value.

    4. Reference to more detail on the interface.

      1. Example:

  32. Interface #32

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: When deactivate_profile() is called on a Cray and the job has neither pcap_node or pcap_accelerator set, a message will be logged by MoM using logjobmsg.

    4.  Reference to more detail on the interface.

      1. Example:

  33. Interface #33

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis:  If Cray RUR is configured but the file created by the output plugin has a permission problem, a message will be logged by MoM using logjobmsg.

    4. Reference to more detail on the interface.

      1. The file owner must be 0 and it must not be writable by other.

      2. Example:

  34. Interface #34

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis:  If Cray RUR is configured but the file created by the output plugin can be read, a message will be logged by MoM using logjobmsg.

    4. Reference to more detail on the interface.

      1. Example

  35. Interface #35

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: If the file created by the RUR output plugin can be read but the energy value cannot be parsed, a message will be logged by MoM using logjobmsg.

    4. Reference to more detail on the interface.

      1. A python exception error string will be output as part of the message.

      2. Example

  36. Interface #36

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: If the file created by the RUR output plugin can be read but the Cray energy RUR plugin has not been enabled, a message will be logged by MoM using logjobmsg.

    4. Reference to more detail on the interface.

      1. Example

  37. Interface #37

    1. Visibility: Public

    2. Change Control: Unstable

    3. Synopsis: When the energy for a job is successfully obtained from RUR, MOM will log one of three possible messages using logjobmsg.

    4. Reference to more detail on the interface.

      1. If no energy value was obtained from capmc:

      2. If the energy value from capmc was smaller than what was obtained from RUR:

      3. If the energy value from capmc was greater than or equal to what was obtained from RUR:

  38. Interface #38

    1. Visibility: Public

    2. Change Control: Unstable