EAR commands

EAR offers a set of commands which help both users and administrators to interact with different components:

• Commands to retrieve data stored in the DB: eacct and ereport.
• Commands to control and temporary modify cluster settings: econtrol.
• Commands to create/update/clean the DB: edb_create, edb_clean_pm and edb_clean_apps.
• A command to load transparently the EAR Library on systems where the batch scheduler has not a plug-in nor some use case isn't supported (e.g., running an OpenMPI application on SLURM systems through the mpirun command): erun.
• A command to show current EAR installation information: ear-info.

Commands belonging to the first three categories read the EAR configuration file (ear.conf) to determine whether the user is authorized, as some of them has some features (or the wall command) only available that set of users. Root is a special case, it doesn't need to be included in the list of authorized users. Some options are disabled when the user is not authorized.

NOTE EAR module must be loaded in your environment in order to use EAR commands.

[[TOC]]

EAR job Accounting (eacct)

The eacct is a simple command to see a jobs' energy accounting information. It can also retrieve EARL events that occurred on a job execution.

The command uses the EAR Configuration file to determine whether the user running it is authorized, as non-privileged users can only access their information. It provides the following options.

    -h      displays this message
    -v      displays current EAR version
    -u      specifies the user whose applications will be retrieved. Only available to privileged users. [default: all users]
    -j      specifies the job id and step id to retrieve with the format [jobid.stepid] or the format [jobid1,jobid2,...,jobid_n].
            A user can only retrieve its own jobs unless said user is privileged. [default: all jobs]
    -a      specifies the application names that will be retrieved. [default: all app_ids]
    -c      specifies the file where the output will be stored in CSV format. [default: no file]
    -t      specifies the energy_tag of the jobs that will be retrieved. [default: all tags].
    -s      specifies the minimum start time of the jobs that will be retrieved in YYYY-MM-DD. [default: no filter].
    -e      specifies the maximum end time of the jobs that will be retrieved in YYYY-MM-DD. [default: no filter].
    -l      shows the information for each node for each job instead of the global statistics for said job.
    -x      shows the last EAR events. Nodes, job ids, and step ids can be specified as if it were showing job information.
    -m      prints power signatures regardless of whether mpi signatures are available or not.
    -r      shows the EAR loop signatures. Nodes, job ids, and step ids can be specified as if were showing job information.
    -o      modifies the -r option to also show the corresponding jobs. Should be used with -j.
    -n      specifies the number of jobs to be shown, starting from the most recent one. [default: 20][to get all jobs use -n all]
    -f      specifies the file where the user-database can be found. If this option is used, the information will be read from the file and not the database.
    -b      verbose mode for debugging purposes

The basic usage of eacct retrieves the last 20 applications (by default) of the user executing it. If a user is privileged, they may see all users applications. The default behaviour shows data from each job-step, aggregating the values from each node in said job-step. If using SLURM as a job manager, a sb (sbatch) job-step is created with the data from the entire execution. A specific job may be specified with -j option.

Below table shows some examples of eacct usage.

Command line	Description
eacct	Shows last 20 jobs executed by the user.
eacct -j <JobID>	Shows data of the job <JobID>, one row for each step of the job.
eacct -j <JobID>.<StepID>	Shows data of the step <StepID> of job <JobID>.
eacct -j <JobIDx>,<JobIDy>,<JobIDz>	Shows data of jobs (one row per step) <JobIDx>,<JobIDy> and <JobIDz>.

The command shows a pre-selected set of columns:

Column field	Description
JOB-STEP	JobID and StepID reported. JobID-sb is shown for the sbatch step in SLURM systems.
USER	The username of the user who executed the job.
APPLICATION	Job’s name or executable name if job name is not provided.
POLICY	Energy optimization policy name. MO means for monitoring, ME for min_energy, MT for min_time and NP is the job ran without EARL.
NODES	Number of nodes involved in the job run.
AVG/DEF/IMC(GHz)	Average CPU frequency, default frequency and average uncore frequency. Includes all the nodes for the step. In GHz.
TIME(s)	Average step execution time along all nodes, in seconds.
POWER(W)	Average node power along all the nodes, in Watts.
GBS	CPU main memory bandwidth (GB/second). Hint for CPU/Memory bound classification.
CPI	CPU Cycles per Instruction. Hint for CPU/Memory bound classification.
ENERGY(J)	Accumulated node energy. Includes all the nodes. In Joules.
GFLOPS/W	CPU+GPU GFlops per Watt. Hint for energy efficiency. The metric uses the number of operations, not instructions.
IO(MBS)	I/O (read and write) Mega Bytes per second.
MPI%	Percentage of MPI time over the total execution time. It’s the average including all the processes and nodes.

If EAR supports GPU monitoring/optimisation, the following columns are added:

Column field	Description
G-POW (T/U)	Average GPU power. Accumulated per node and averaged along involved nodes. T mean for total GPU power consumed (even the job is not using any or all of GPUs in one node). U means for only used GPUs on each node.
G-FREQ	Average GPU frequency. Per node and average of all the nodes.
G-UTIL(G/MEM)	GPU utilization and GPU memory utilization.

For node-specific information, the -l (i.e., long) option provides detailed accounting of each individual node. In addition, eacct shows an additional column: VPI(%). The VPI means the percentage of AVX512 instructions over the total number of instructions.

For runtime data (EAR loops) one may retrieve them with -r. Both Job and Step ID filtering works. To easily transfer command's output, -c option saves it in .csv format. Both aggregated and detailed accountings are available, as well as filtering:

Command line	Description
eacct -j <JobID> -c test.csv	Adds to the file test.csv all metrics shown above for each step if the job <JobID>.
eacct -j <JobID>.<StepID> -l -c test.csv	Appends to the file test.csv all metrics in the EAR DB for each node involved in step <StepID> of job <JobID>.
eacct -j <JobID>.<StepID> -r -c test.csv	Appends to the file test.csv all metrics in EAR DB for each loop of each node involved in step <StepID> of job <JobID>.

When requesting long format (i.e., -l option) or runtime metrics (i.e., -r option) to be stored in a CSV file (i.e., -c option), header names change from the output shown when you don't request CSV format. Below table shows header names of CSV file storing long information about jobs. Bold fields indicate they are just filled when the EAR Library (EARL) is enabled. Format is the same used by the csv report plug-in.

Field name	Description
JOBID	The JobID.
STEPID	The StepID.
APPID	The EARL application ID used to identify the workload. This value is useful to identify different applications executed in a workflow within the same job-step.
USERID	The username of the user who executed the job.
GROUPID	The group name of the user who executed the job.
ACCOUNTID	The account name of the user who executed the job.
JOBNAME	Job’s name or executable name if job name is not provided.
ENERGY_TAG	The energy tag used if the user set one for its job step.
JOB_START_TIME	The Unix Epoch timestamp in seconds when the job-step started.
JOB_END_TIME	The Unix Epoch timestamp in seconds when the job-step ended.
JOB_EARL_START_TIME	The Unix Epoch timestamp in seconds when the EARL started monitoring the job-step, i.e., the application start time.
JOB_EARL_END_TIME	The Unix Epoch timestamp in seconds when the EARL ended monitoring the job-step, i.e., the application end time.
POLICY	Energy optimization policy name used by the EARL. MO means for monitoring-only, ME for min_energy, MT for min_time and NP is the job ran without EARL.
POLICY_TH	The policy threshold used by the optimization policy used by EARL.
JOB_NPROCS	The number of processes involved in the application.
JOB_TYPE	The job type.
JOB_DEF_FREQ	The default frequency at which the job started.
EARL_ENABLED	Indicates whether the job-step ran with the EARL enabled.
EAR_LEARNING	Whether the application was run in the learning phase.
NODENAME	The node name the rest of the row information belongs to.
AVG_CPUFREQ_KHZ	Average CPU frequency of the job step executed in the node, expressed in kHz. This value is computed by the EARL.
AVG_IMCFREQ_KHZ	Average uncore frequency of the job step executed in the node, expressed in kHz. Default data fabric frequency on AMD sockets. This value is computed by the EARL.
DEF_FREQ_KHZ	The default frequency of the job step executed in the node, expressed in kHz. This value corresponds to the default frequency the EAR Library sets at the beginning, and it has the same value as JOB_DEF_FREQ.
TIME_SEC	Execution time period (in seconds) which comprises the application metrics reported by the EARL.
CPI	CPU Cycles per Instruction. Hint for CPU/Memory bound classification.
TPI	Memory transactions per Instruction. Hint for CPU/Memory bound classification.
MEM_GBS	CPU main memory bandwidth (GB/second). Hint for CPU/Memory bound classification.
IO_MBS	I/O (read and write) Mega Bytes per second.
PERC_MPI	Percentage of TIME_SEC spent in MPI calls.
DC_NODE_POWER_W	Average node power along the time period, in Watts. This value differs from NODEMGR_DC_NODE_POWER_W in that it is computed and reported by the EARL.
DRAM_POWER_W	Average DRAM power along the time period, in Watts. Not available on AMD sockets. This value differs from NODEMGR_DRAM_POWER_W in that it is computed and reported by the EARL.
PCK_POWER_W	Average RAPL package power along the time period, in Watts. This value shows the aggregated power of all sockets in a package. This value differs from NODEMGR_PCK_POWER_W in that it is computed and reported by the EARL.
CYCLES	Total number of cycles retrieved along the time period.
INSTRUCTIONS	Total number of instructions retrieved along the time period.
CPU_GFLOPS	Total number of giga-Floating point operations per second along the time period.
CPU_UTIL	The CPU time of the application.
L1_MISSES	Total number of L1 cache misses along the time period.
L2_MISSES	Total number of L2 cache misses along the time period.
L3_MISSES	Total number of L3/LLC cache misses along the time period.
SPOPS_SINGLE	Total number of single precision 64 bit floating point operations.
SPOPS_128	Total number of single precision 128 bit floating point operations.
SPOPS_256	Total number of single precision 256 bit floating point operations.
SPOPS_512	Total number of single precision 512 bit floating point operations.
DPOPS_SINGLE	Total number of double precision 64 bit floating point operations.
DPOPS_128	Total number of double precision 128 bit floating point operations.
DPOPS_256	Total number of double precision 256 bit floating point operations.
DPOPS_512	Total number of double precision 512 floating point 512 operations.
NODEMGR_DC_NODE_POWER_W	Average node power along the time period, in Watts. This value differs from DC_NODE_POWER_W in that it is computed and reported by the Node Manager (the EARD) independently on whether the EARL was enabled.
NODEMGR_DRAM_POWER_W	Average DRAM power along the time period, in Watts. Not available on AMD sockets. This value differs from DRAM_POWER_W in that it is computed and reported by the Node Manager (the EARD) independently on whether the EARL was enabled.
NODEMGR_PCK_POWER_W	Average RAPL package power along the time period, in Watts. This value shows the aggregated power of all sockets in a package. This value differs from PCK_POWER_W in that it is computed and reported by the Node Manager (the EARD) independently on whether the EARL was enabled.
NODEMGR_MAX_DC_POWER_W	The peak DC node power computed by the Node Manager.
NODEMGR_MIN_DC_POWER_W	The minimum DC node power computed by the Node Manager.
NODEMGR_TIME_SEC	Execution time period (in seconds) which comprises the job-step metrics reported by the Node Manager.
NODEMGR_AVG_CPUFREQ_KHZ	The average CPU frequency computed by the Node Manager during the job-step execution time.
NODEMGR_DEF_FREQ_KHZ	The default frequency set by the Node Manager when the job-step began.

If EARL supports GPU monitoring/optimisation, the following columns are added:

Field name	Description
GPUx_POWER_W	Average GPUx power, in Watts.
GPUx_FREQ_KHZ	Average GPUx frequency, in kHz.
GPUx_MEM_FREQ_KHZ	Average GPux memory frequency, in kHz.
GPUx_UTIL_PERC	Average percentage of GPUx utilization.
GPUx_MEM_UTIL_PERC	Average percentage of GPUx memory utilization.
GPUx_GFLOPS	GPUx GFLOPS.
GPUx_TEMP	AverageGPUx temperature.
GPUx_MEMTEMP	AverageGPUx memory temperature.

For runtime metrics (i.e., -r option), USERID, GROUPID, JOBNAME, USER_ACC, ENERGY_TAG (as energy tags disable EARL), POLICY and POLICY_TH are not stored at the CSV file. However, the iteration time (in seconds) is present on each loop as ITER_TIME_SEC, as well as a timestamp (i.e., TIMESTAMP) with the Unix Epoch elapsed time in seconds.

EAR system energy Report (ereport)

The ereport command creates reports from the energy accounting data from nodes stored in the EAR DB. It is intended to use for energy consumption analysis over a set period of time, with some additional (optional) criteria such as node name or username.

Usage: ereport [options]
Options are as follows:
        -s start_time            indicates the start of the period from which the energy consumed will be computed. Format: YYYY-MM-DD. Default: end_time minus insertion time*2.
        -e end_time              indicates the end of the period from which the energy consumed will be computed. Format: YYYY-MM-DD. Default: current time.
        -n node_name |all        indicates from which node the energy will be computed. Default: none (all nodes computed) 
                                         'all' option shows all users individually, not aggregated.
        -u user_name |all        requests the energy consumed by a user in the selected period of time. Default: none (all users computed). 
                                         'all' option shows all users individually, not aggregated.
        -t energy_tag|all        requests the energy consumed by energy tag in the selected period of time. Default: none (all tags computed). 
                                         'all' option shows all tags individually, not aggregated.
        -i eardbd_name|all       indicates from which eardbd (island) the energy will be computed. Default: none (all islands computed) 
                                         'all' option shows all eardbds individually, not aggregated.
        -g                       shows the contents of EAR's database Global_energy table. The default option will show the records for the two previous T2 periods of EARGM.
                                         This option can only be modified with -s, not -e
        -x                       shows the daemon events from -s to -e. If no time frame is specified, it shows the last 20 events. 
        -v                       shows current EAR version. 
        -h                       shows this message.

Examples

The following example uses the 'all' nodes option to display information for each node, as well as a start_time so it will give the accumulated energy from that moment until the current time.

[user@host EAR]$ ereport -n all -s 2018-09-18 
     Energy (J)       Node      Avg. Power (W)
     20668697         node1        146
     20305667         node2        144
     20435720         node3        145
     20050422         node4        142
     20384664         node5        144
     20432626         node6        145
     18029624         node7        128

This example filters by EARDBD host (one per island typically) instead:

[user@host EAR]$ ereport -s 2019-05-19 -i all
     Energy (J)        Node     
     9356791387        island1 
    30475201705        island2
    37814151095        island3 
    28573716711        island4 
    29700149501        island5 
    26342209716        island6

And to see the state of the cluster's energy budget (set by the sysadmin) you can use the following:

[user@host EAR]$ ereport -g 
Energy%  Warning lvl            Timestamp       INC th      p_state    ENERGY T1    ENERGY T2      TIME T1      TIME T2        LIMIT       POLICY
111.486          100  2019-05-22 10:31:34            0          100          893      1011400       907200          600       604800 EnergyBudget 
111.492          100  2019-05-22 10:21:34            0          100          859      1011456       907200          600       604800 EnergyBudget 
111.501          100  2019-05-22 10:11:34            0          100          862      1011533       907200          600       604800 EnergyBudget 
111.514          100  2019-05-22 10:01:34            0          100          842      1011658       907200          600       604800 EnergyBudget 
111.532          100  2019-05-22 09:51:34            0          100          828      1011817       907200          600       604800 EnergyBudget 
111.554            0  2019-05-22 09:41:34            0            0          837      1012019       907200          600       604800 EnergyBudget 

EAR Control (econtrol)

The econtrol command modifies cluster settings (temporally) related to power policy settings. These options are sent to all the nodes in the cluster.

NOTE Any changes done with econtrol will not be reflected in ear.conf and thus will be lost when reloading the system.

Usage: econtrol [options]
        --status                                ->requests the current status for all nodes. The ones responding show the current 
                                                        power, IP address and policy configuration. A list with the ones not
                                                        responding is provided with their hostnames and IP address.
                                                        --status=node_name retrieves the status of that node individually.
        --type          [status_type]           ->specifies what type of status will be requested: hardware,
                                                        policy, full (hardware+policy), app_node, app_master, eardbd, eargm or power. [default:hardware]
        --power                                 ->requests the current power for the cluster. 
                                                        --power=node_name retrieves the current power of that node individually.
        --set-freq      [newfreq]               ->sets the frequency of all nodes to the requested one
        --set-def-freq  [newfreq]  [pol_name]   ->sets the default frequency for the selected policy 
        --set-max-freq  [newfreq]               ->sets the maximum frequency
        --set-powercap  [new_cap]               ->sets the powercap of all nodes to the given value. A node can be specified
                                                         after the value to only target said node.
        --hosts         [hostlist]              ->sends the command only to the specified hosts. Only works with status, power_status,
                                                         --power and --set-powercap
        --restore-conf                          ->restores the configuration for all nodes
        --active-only                           ->supresses inactive nodes from the output in hardware status.
        --health-check                          ->checks all EARDs and EARDBDs for errors and prints all that are unresponsive.
        --domain [domain:target]		->sends the requested command to the requested targets, effectively filtering
							which nodes receive the message. Available domains are: tag, node, subcluster/eargmid, island.

        --mail [address]                        ->sends the output of the program to address.
        --ping                                  ->pings all nodes to check whether the nodes are up or not. Additionally,
                                                        --ping=node_name pings that node individually.
        --version                               ->displays current EAR version.
        --help                                  ->displays this message.

econtrol's status is a useful tool to monitor the nodes in a cluster. The most basic usage is the hardware status (default type) which shows basic information of all the nodes.

[user@login]$ econtrol --status
hostname      power   temp    freq    job_id  stepid
   node2        278    66C    2.59      6878       0
   node3        274    57C    2.59      6878       0
   node4         52    31C    1.69         0       0

INACTIVE NODES
node1   192.0.0.1

The application status type can be used to retrieve all currently running jobs in the cluster. app_master gives a summary of all the running applications while app_node gives detailed information of each node currently running a job.

[user@login]$ econtrol --status --type=app_master
Job-Step    Nodes   DC power      CPI      GBS   Gflops     Time Avg Freq
  6878-0        2     280.13     0.37    24.39   137.57    54.00     2.59

[user@login]$ econtrol --status --type=app_node
Node id     Job-Step   M-Rank   DC power      CPI      GBS   Gflops     Time Avg Freq
  node2       6878-0        0     280.13     0.37    24.39   137.57    56.00     2.59
  node3       6878-0        1     245.44     0.37    24.29   136.40    56.00     2.59

A list of nodes can be specified to only target those for the commands:

[user@login]$ econtrol --status --hosts node2,node3
hostname      power   temp    freq    job_id  stepid
   node2        278    66C    2.59      6878       0
   node3        274    57C    2.59      6878       0

[user@login]$ econtrol --status --hosts island[0,1]node[2-3]
hostname      power   temp    freq    job_id  stepid
island0node2    278    66C    2.59         0       0
island0node3    274    57C    2.59         0       0
island1node2    273    56C    2.59         0       0
island1node3    272    57C    2.59         0       0

If only one node is targeted for a status, one may do:

[user@login]$ econtrol --status=island0node2
hostname      power   temp    freq    job_id  stepid
island0node2    278    66C    2.59         0       0

For any other command type (including status):

[user@login]$ econtrol --status --hosts island0node2
hostname      power   temp    freq    job_id  stepid
island0node2    278    66C    2.59         0       0

[user@login]$ econtrol --restore-conf --hosts island0node2

[user@login]$ econtrol --status --domain node:island0node2
hostname      power   temp    freq    job_id  stepid
island0node2    278    66C    2.59         0       0

Furthermore, the domain option may be used to filter out any nodes not belonging to a specified domain.

To only send a command to a single island (as defined in ear.conf):

[user@login]$ econtrol --restore-conf --domain island:2

To send to all the nodes that belong to a tag (as defined in ear.conf), regardless of their island or any other configuration:

[user@login]$ econtrol --set-powercap 400 --domain tag:cpu_only

One can also do use a double filter:

[user@login]$ econtrol --set-freq 3100000 --domain tag:cpu_only island:3

NOTE: Using domain filtering with a hostlist specification is not supported and may cause some errors.

Database commands

edb_create

Creates the EAR DB used for accounting and for the global energy control. Requires root access to the MySQL server. It reads the ear.conf to get connection details (server IP and port), DB name (which may or may not have been previously created) and EAR's default users (which will be created or altered to have the necessary privileges on EAR's database).

Usage:edb_create [options]
        -p       Specify the password for MySQL's root user.
        -o       Outputs the commands that would run.
        -r       Runs the program. If '-o' this option will be overriden.
        -h       Shows this message.

edb_clean_pm

Cleans periodic metrics from the database. Used to reduce the size of EAR's database, it will remove every Periodic_metrics entry older than num_days:

Usage:./src/commands/edb_clean_pm [options]
	-d num_days		REQUIRED: Specify how many days will be kept in database. (default: 0 days).
	-p			Specify the password for MySQL's root user.
	-o			Print the query instead of running it (default: off).
	-r			Execute the query (default: on).
	-h			Display this message.
	-v			Show current EAR version.

edb_clean_apps

Removes applications from the database. It is intended to remove old applications to speed up queries and free up space. It can also be used to remove specific applications from database. It removes ALL the information related to those jobs (the following tables will be modified for each job: Loops, if they exist; GPU_signatures, if they exist; Signatures, if they exist; Power signatures, Applications, and Jobs).

It is recommended to run the application with the -o option first to ensure that the queries that will be executed are correct.

Usage:edb_clean_apps [-j/-d] [options]
	-p		The program will request the database user's password.
	-u user		Database user to execute the operation (it needs DELETE privileges). [default: root]
	-j jobid.stepid	Job id and step id to delete. If no step_id is introduced, every step within the job will be deleted
	-d ndays	Days to preserve. It will delete any jobs older than ndays.
	-o		Prints out the queries that would be executed. Exclusive with -r. [default:on]
	-r		Runs the queries that would be executed. Exclusive with -o. [default:off]
	-l		Deletes Loops and its Signatures. [default:off]
	-a		Deletes Applications and related tables. [default:off]
	-h		Displays this message

erun

erun is a program that simulates all the SLURM and EAR SLURM Plug-in pipeline. It was designed to provide compatibility between MPI implementations not fully compatible with SLURM SPANK plug-in mechanism (e.g., OpenMPI), which is used to set up EAR at job submission. You can launch erun with the --program option to specify the application name and arguments. See the usage below:

erun --help

This is the list of ERUN parameters:
Usage: ./erun [OPTIONS]

Options:
    --job-id=<arg>	Set the JOB_ID.
    --nodes=<arg>	Sets the number of nodes.
    --program=<arg>	Sets the program to run.
    --clean		Removes the internal files.
    
SLURM options:
...

The syntax to run an MPI application with erun has the form mpirun -n <X> erun --program='my_app arg1 arg2 .. argN'. Therefore, mpirun will run X erun processes. Then, erun will launch the application my_app with the arguments passed, if specified. You can use as many parameters as you want but the semicolons have to cover all of them in case there are more than just the program name.

erun will simulate on the remote node both the local and remote pipelines for all created processes. It has an internal system to avoid repeating functions that are executed just one time per job or node, like SLURM does with its plugins.

IMPORTANT NOTE If you are going to launch n applications with erun command through a sbatch job, you must set the environment variable SLURM_STEP_ID to values from 0 to n-1 before each mpirun call. By this way erun will inform the EARD the correct step ID to be stored then to the Database.

The --job-id and --nodes parameters create the environment variables that SLURM would have created automatically, because it is possible that your application make use of them. The --clean option removes the temporal files created to synchronize all ERUN processes.

Also you have to load the EAR environment module or define its environment variables in your environment or script:

Variable	Parameter
EAR_INSTALL_PATH=<path>	prefix=<path>
EAR_TMP=<path>	localstatedir=<path>
EAR_ETC=<path>	sysconfdir=<path>
EAR_DEFAULT=<on/off>	default=<on/off>

ear-info

ear-info is a tool created to quickly view useful information about the current EAR installation of the system. It shows relevant details for both users and administrators, such as configuration defaults, installation paths, etc.

[user@hostname ~]$ ear-info -h
Usage: ear-info [options]
	--node-conf[=nodename]
	--help

The tool prints out information without giving it any argument. It shows a resume about EAR parameters set at compile time, as well as some installation dependent configuration:

• The current EAR version.
• The maximum number of CPUs/processors supported.
• The maximum number of sockets supported.
• Whether the current installation provides support for GPUs.
• The default optimization policy.
• Whether the EAR Library is enabled by default on job submission.
• Information about EAR's Uncore Frequency Scaling policy (eUFS) configuration.
• EAR's dynamic load balancing policy.
• EAR's application phase classification.
• EAR's MPI stats collection feature.
• EAR data reporting mechanism configuration.

Below there is an example of the output:

EAR version 4.3
Max CPUS supported set to 256
Max sockets supported set to 4
EAR installed with GPU support MAX_GPUS 8
Default cluster policy is monitoring
EAR optimization  by default set to 0


Environment configuration section..............
                                   eUFS  1
                              eUFS limit 0.02
                   Load balanced enabled 1
                         Load Balance th 0.80
             Use turbo for critical path 1
                               Use turbo 0
                          Exclusive mode 0
                         Use EARL phases 1
                       Use energy models 1
     Max IMC frequency (0 = not defined) 0
     Min IMC frequency (0 = not defined) 0
 GPU frequency/pstate (0 = max GPU freq) 0
                        MPI optimization 0
                          MPI statistics 0
                             App. Tracer no trace
               App. Extra report plugins no extra plugins
            App. reporting loops to EARD 1
............................................


HACK section............................
                            Install path /hpc/base/ctt/packages/EAR/ear
              Energy optimization policy 
                        GPU power policy /hpc/base/ctt/packages/EAR/ear/lib/plugins/policies/gpu_monitoring.so
                        CPU power  model /hpc/base/ctt/packages/EAR/ear/lib/plugins/policies/gpu_monitoring.so
                 CPU shared power  model /hpc/base/ctt/packages/EAR/ear/lib/plugins/models/cpu_power_model_default.so
............................................

EAR was designed to be installed on heterogeneous systems, so some configuration parameters that are applied to a set of nodes identified by different tags. The --node-conf flag can be used to request additional information about a specific node. Configuration related to EAR's power capping sub-system, default optimization policies configuration and other parameters associated with the node requested are retrieved. You can read the EAR configuration section for more details about how EAR uses tags to identify and configure different kind of nodes on a given heterogeneous system.

Contact with ear-support@bsc.es for more information about the nomenclature used by ear-info's output.