Pith. sign in

REVIEW 4 major objections 6 minor 38 references

Strategies to Measure Energy Consumption Using RAPL During Workflow Execution on Commodity Clusters

T0 review · 4 major / 6 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Cluster users can capture full RAPL workflow energy with a shell script or Nextflow plugin.

desk verdict Honest and useful engineering comparison, but the empirical tables are built from post hoc interval extraction rather than end-to-end runs, so the coverage percentages are provisional. read the letter →

arxiv 2505.09375 v2 pith:7QE2N2OD submitted 2025-05-14 cs.DC

Philipp Thamm , Ulf Leser This is my paper · ORCID
classification cs.DC
keywords RAPLenergymeasurementscientificworkflowsNextflowKubernetesconsumptionclustercomputingworkflowmonitoringIPMI
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper addresses a practical gap: on managed Kubernetes clusters, reading Intel RAPL energy counters for a running scientific workflow is complicated by limited privileges, multi-node scheduling, and container constraints. The authors implement and compare four strategies—measurement managed inside the workflow, a wrapping shell script, a Nextflow plugin, and Prometheus-based monitoring—against eight design criteria. Their experiments with three real workflows show that the shell-script method captures the full RAPL-measurable workflow energy, while the plugin and task-based methods miss between 0.19% and 7.67% depending on workflow runtime. They conclude that the shell script and the Nextflow plugin are both effective and easy to implement, and that task-level measurement is exact only when one task runs at a time.

What carries the argument

The central mechanism is the coordination of measurement start and stop around workflow execution: a privileged monitoring pod on each node continuously reads the RAPL model-specific registers (MSRs) and logs timestamped energy values, and the four methods differ in what triggers the measurement. The shell script triggers measurement before launching the workflow and stops it when the workflow ends, which is why it is the only method with full coverage; the Nextflow plugin hooks into workflow start and task boundaries; task-based management embeds start/stop signals into the workflow itself; Prometheus polls continuously via hwmon/IPMI. The load-bearing identity is that RAPL MSR delta over a time interval equals workflow energy, provided no other workload runs on the node.

What would settle it

Run the same three workflows on the same two-node cluster while measuring node-level power with a calibrated external physical power meter; if the shell-script-wrapped RAPL total differs systematically from the meter (beyond the known 21-37% of non-CPU/DRAM components such as disks, network, fans, and power supply), then the shell-script baseline is not the true energy of the workflow and the coverage percentages measured against it would shift accordingly. A second check would be to run an idle node for one hour and compare RAPL Package+DRAM deltas to the meter, isolating the fixed offset.

Watch

Extended reading notes

Core claim

The paper's central claim is that on a commodity Kubernetes cluster, RAPL-based energy measurement can be achieved without cluster-administrator intervention by wrapping the Nextflow workflow in a shell script or by using a Nextflow plugin, and that both approaches capture essentially all of the RAPL-measurable energy of the workflow. In head-to-head measurements on three workflows (RNASeq, Quantms, Rangeland), the shell-script method is the only one that starts measurement before workflow initialization and therefore captures 100% of the RAPL-visible energy; the plugin and task-based methods miss between 0.19% and 7.67% of that energy, with the gap driven mainly by the few seconds of startup delay before measurement begins, amortized over total runtime. Prometheus, by contrast, reports deviations from the shell-script baseline that are not explained by polling interval alone, leaving its energy-reporting mechanism as an open question.

Load-bearing premise

The paper assumes that RAPL MSR readings correctly represent the energy that a workflow task actually consumes on a cluster node, and it treats the shell-script method as the true 100% reference even though no physical power meter was available to verify RAPL itself on the cluster hardware.

Editorial extensions

If this is right

  • Workflow users on managed clusters can obtain near-complete RAPL energy data with a single wrapper script, with no cluster-administrator involvement beyond deploying privileged monitoring pods.
  • The roughly 0.2% to 7.7% gap between the full-coverage shell-script method and plugin/task-based methods is a fixed startup delay that shrinks for longer workflows, so the plugin becomes effectively equivalent for long-running production workflows.
  • Per-task energy measurement is reliable only for sequential, non-overlapping tasks longer than one second; concurrent or sub-second tasks require heuristics such as CPU utilization, so per-task data should be labeled as approximate in those cases.
  • Prometheus-based energy readings can disagree with RAPL by more than 30% on short workflows and even on idle periods, so it should not be assumed that Prometheus returns the same underlying RAPL values.
  • A measurement method's coverage can be quantified as the fraction of the shell-script baseline RAPL energy captured, giving future methods a simple comparable metric.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The 0.19% to 7.67% coverage gaps imply a practical rule of thumb: for workflows running longer than about 30 minutes, the startup-delay penalty of plugin-based measurement is negligible, making the plugin the default choice, whereas the shell script matters mainly for short workflows or when 100% coverage is a formal requirement.
  • Because RAPL Package and DRAM domains cover roughly 63-79% of a server's total energy, these methods measure workflow CPU-and-memory energy only; any workflow energy reported by these tools should be interpreted as 'CPU plus DRAM energy', not total node energy, and energy-optimization claims should be scoped accordingly.
  • The paper's measurement strategy could be reused to benchmark other monitoring stacks: any energy reporter whose output disagrees with the RAPL shell-script baseline on idle nodes is likely adding non-RAPL components or applying its own estimation, exactly as suspected for Prometheus.
  • A natural next experiment would be to run the shell-script method against a physical wall power meter on the cluster's two-node testbed to check the assumed accuracy of RAPL itself for containerized workflow workloads; a systematic under- or over-reporting there would change the meaning of all coverage percentages.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper addresses the practical problem of measuring the energy consumption of scientific workflows executed on Kubernetes clusters using Intel RAPL hardware counters. It presents four measurement strategies: managing measurement as part of the workflow (task-based), wrapping workflow execution in a shell script, integrating a Nextflow plugin, and using Prometheus-based monitoring. The methods are compared against eight design criteria (e.g., fault handling, portability, overhead) and implemented for three nf-core workflows (RNASeq, Quantms, Rangeland) on a commodity cluster. The empirical evaluation, based on five repeated runs per workflow, reports that the shell-script method captures the full RAPL-measurable workflow energy, while plugin and task-based methods miss between 0.19% and 7.67% depending on workflow runtime; Prometheus values differ by -3.94% to +36.31% from the shell-script baseline. The authors conclude that the shell-script and Nextflow plugin approaches are both effective and easy to implement, with Prometheus also recommended when its additional software is acceptable.

Significance. If the findings hold, the paper provides cluster users with a practical, low-cost way to obtain near-complete RAPL-based energy data for workflow execution, and it offers a useful eight-criterion checklist for evaluating energy-measurement approaches. The paper is notably transparent about its main limitations: Section 2.3 explicitly states that RAPL accuracy could not be validated against physical power meters on the cluster hardware, and Section 7.1 lists this as future work. The repeated experimental runs (five per workflow), the LoC-based complexity comparison, and the clear exposition of pitfalls such as counter overflow, privilege requirements, and container limitations are strengths. The principal weakness is that the empirical comparison is performed by extracting intervals from a single RAPL trace rather than by executing each method as an independent end-to-end system, so the reported percentages primarily characterize interval-selection logic rather than the implemented methods' runtime behavior; this limits the direct support for the paper's headline claims.

major comments (4)
  1. [Section 5.3 and Tables 4-6, Figure 7] The empirical comparison does not exercise the methods as implemented. The paper states that 'it is not necessary to run individual experiments for each method separately' and instead records one continuous RAPL trace while determining the start and stop times of each method, then extracts the captured energy from the same log. As a result, Tables 4-6 and Figure 7 report the energy implied by the chosen start/stop boundaries, not the energy that the actual shell-script polling loop, daemon file-polling mechanism, plugin hooks, or task-based coordination would capture in real execution. Failure modes that matter for the central claim—kubectl polling latency, daemon polling delay, plugin hook timing, log-file flushing, overflow handling, and fault reactions—are never exercised. The claim that the shell-script and plugin are 'effective' therefore rests on implementation plausibility and LoC counts rather than on measured end-to-end validation. The authors should either run each method as a separate end-to-end experiment or explicitly reframe the results as 'energy captured under the interval definitions used by each method.'
  2. [Section 2.3 and Section 7.1] The accuracy of RAPL on cluster hardware is assumed, not established. The authors acknowledge they cannot confirm RAPL accuracy for scientific workflows on compute clusters because they lack physical power meters, and all comparisons use the shell-script value as the reference. If RAPL under- or over-reports on the Intel Xeon Silver 4314 CPUs (for example, because the Package and DRAM domains exclude storage and network energy), then the '100% coverage' attributed to the shell-script and the relative percentages for other methods are measured against a possibly biased reference. This limitation is stated transparently, but the abstract and conclusion do not carry the corresponding qualification. The paper should consistently state that the methods capture RAPL-measurable energy, not total node energy, and should clarify whether the coverage percentages are intended as RAPL-relative or physical-energy-relative.
  3. [Section 5.4, Tables 5-6, and Section 8] The Prometheus results exhibit a large, unexplained discrepancy: for the short workflows Quantms and Rangeland, Prometheus reports 30-36% more energy than the shell-script baseline, while for the longer RNASeq workflow it reports about 4% less, and changing the scraping interval from 30s to 10s increases the RNASeq discrepancy instead of reducing it. The authors hypothesize possible causes but state that 'finding the exact nature of these differences remains future work.' Because the conclusion recommends Prometheus as one of the most beneficial methods when its software is available, an unresolved systematic discrepancy in the magnitude of the measured energy directly weakens that recommendation. The paper should either identify the cause (e.g., verify whether Prometheus includes additional metrics or different time windows) or temper the recommendation to note that Prometheus's absolute values require external validation.
  4. [Section 5.3 and Tables 4-6] Only averages over five runs are reported, with no per-run values, standard deviations, or statistical tests. The RNASeq differences between methods (0.19% for the plugin versus 0.36% for the task-based method) are small and may be within run-to-run variation; without dispersion measures, the claim that the plugin and task-based methods miss 'about 0.19%' and 'about 0.36%' is not robust. The authors should report per-run data or at least standard deviations and confidence intervals for the key comparisons, especially because the paper's quantitative conclusions about method equivalence rest on these averages.
minor comments (6)
  1. [Section 4.2.1] The text says the method 'does not fulfill four of our seven criteria,' but Table 1 lists eight criteria including Multi-tenancy; the count should be eight.
  2. [Section 3.4 versus Section 2.3] Section 3.4 states that the register is 'limited to 38 bits,' while Section 2.3 says the registers are limited to 32 or 36 bits depending on CPU model; these numbers should be reconciled.
  3. [Section 4.2.4] The example Prometheus query uses 'node_hwmon_power_average_watt,' which is a power value, and multiplies by 30 to obtain energy; the text should clarify whether the underlying metric is power or energy and how the multiplication by the scraping interval works.
  4. [Appendix, Figures 9 and 10] Figures 9 and 10 in the appendix are not cited in the main text; they should either be referenced in Section 5 or removed.
  5. [Section 5.2 and Table 3] Table 3 lists RNASeq as having 9 physical tasks, but the modified pipeline described in Section 5.2 names seven tasks (fastp, star index, fastqsplit, star align, samtools, samtools merge, cufflinks); the task count should be clarified.
  6. [Abstract and Section 4.2.4] The abstract mentions 'one additional method using IPMI,' but the fourth method is Prometheus reading energy values through RAPL/IPMI/ACPI; the wording should be adjusted to avoid implying a separate IPMI-only method.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the study reads hardware counters directly and compares interval definitions; the shell-script reference is explicit, not a disguised input.

full rationale

The paper does not fit parameters and then rename them as predictions, nor does it derive a first-principles result from an input that already contains the conclusion. The empirical comparison in Section 5.3 is transparent: all non-Prometheus methods read the same RAPL counters, so the authors record one trace and compute each method's captured energy from the start/stop timestamps corresponding to that method. This is an interval-comparison experiment, not a fitted model. The use of the shell-script as the 100% reference is an explicit measurement convention: Section 4.2.2 states the script starts measurement before workflow initialization and stops it after completion, so bracketing the workflow is part of the method's design. The paper does not present the shell-script value as externally validated ground truth; it explicitly notes in Section 2.3 that RAPL accuracy on cluster workflows cannot be confirmed without physical power meters, and Section 7.1 lists validation as future work. That is a stated scope limitation, not a circular step. The only self-citations (references [2] and [21], coauthored by Ulf Leser) are cited for workflow runtime and memory prediction background, not as load-bearing support for the energy measurement claims. No uniqueness theorem, ansatz, or fitted input is smuggled in via citation. The central empirical finding is therefore self-contained relative to its stated reference, and the paper's caveats are explicit rather than concealed.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

No fitted numeric parameters appear; this is an empirical comparison, not a model fit. The paper introduces no new physical or conceptual entities. The load-bearing assumptions are about RAPL accuracy, the shell-script baseline, and the sufficiency of continuous counter sampling, all of which the authors partially acknowledge as unvalidated.

assumptions (3)
  • domain assumption RAPL energy counters reliably estimate CPU and DRAM energy consumption.
    Invoked in Sections 2.3 and 3. The authors explicitly state they cannot confirm RAPL accuracy for workflow execution on clusters because they lack physical power meters.
  • domain assumption The shell-script method's measurement spans the full workflow execution and can serve as the reference baseline.
    Sections 5.3 and 6 treat shell-script values as 100 percent baseline. This presumes it captures all RAPL-measurable energy, while the other methods are known to start late.
  • domain assumption Continuous MSR sampling at sufficiently small intervals is enough to reconstruct energy without missing counter overflows.
    Section 3.4 explains the overflow problem and the solution is implemented in the daemon pods, but no check against a known external energy value is provided.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Strategies to Measure Energy Consumption Using RAPL During Workflow Execution on Commodity Clusters." pith.science (2026). https://pith.science/paper/7QE2N2OD

@misc{pith2026250509375,
  author       = {Pith},
  title        = {Pith review of: Strategies to Measure Energy Consumption Using RAPL During Workflow Execution on Commodity Clusters},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7QE2N2OD}},
  note         = {Machine review of arXiv:2505.09375}
}
read the original abstract

In science, problems in many fields can be solved by processing datasets using a series of computationally expensive algorithms, sometimes referred to as workflows. Traditionally, the configurations of these workflows are optimized to achieve a short runtime for the given task and dataset on a given (often distributed) infrastructure. However, recently more attention has been drawn to energy-efficient computing, due to the negative impact of energy-inefficient computing on the environment and energy costs. To be able to assess the energy-efficiency of a given workflow configuration, reliable and accurate methods to measure the energy consumption of a system are required. One approach is the usage of built-in hardware energy counters, such as Intel RAPL. Unfortunately, effectively using RAPL for energy measurement within a workflow on a managed cluster with the typical deep software infrastructure stack can be difficult, for instance because of limited privileges and the need for communication between nodes. In this paper, we describe three ways to implement RAPL energy measurement on a Kubernetes cluster while executing scientific workflows utilizing the Nextflow workflow engine. We compare them by utilizing a set of eight criteria that should be fulfilled for accurate measurement, such as the ability to react to workflow faults, portability, and added overhead. We highlight advantages and drawbacks of each method and discuss challenges and pitfalls, as well as ways to avoid them. We also empirically evaluate all methods, and find that approaches using a shell script and a Nextflow plugin are both effective and easy to implement. Additionally, we find that measuring the energy consumption of a single task is straight forward when only one task runs at a time, but concurrent task executions on the same node require approximating per-task energy usage using metrics such as CPU utilization.

Figures

Figures reproduced from arXiv: 2505.09375 by the authors.

Figure 1
Figure 1. The installation locations for external and internal physical power meters [ [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. An overview of the system components covered by each RAPL domain [ [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. A breakdown of the typical power consumption of a physical server [ [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: The communication between the machines when controlling the RAPL measurement [PITH_FULL_IMAGE:figures/full_fig_p011_4.png]
Figure 5
Figure 5. Figure 5: The communication between the machines when controlling the RAPL measurement [PITH_FULL_IMAGE:figures/full_fig_p013_5.png]
Figure 6
Figure 6. Figure 6: The communication between the machines when controlling the RAPL measurement from [PITH_FULL_IMAGE:figures/full_fig_p014_6.png]
Figure 7
Figure 7. Figure 7: The bar chart shows the differences in the total amount of energy measured using a [PITH_FULL_IMAGE:figures/full_fig_p019_7.png]
Figure 8
Figure 8. Figure 8: The bar chart shows the differences in the total amount of energy measured using [PITH_FULL_IMAGE:figures/full_fig_p020_8.png]
Figure 9
Figure 9. Figure 9: The bar chart shows the differences in the total amount of energy measured using a [PITH_FULL_IMAGE:figures/full_fig_p025_9.png]
Figure 10
Figure 10. Figure 10: The bar chart shows the total amount of energy measured using the four approaches on [PITH_FULL_IMAGE:figures/full_fig_p026_10.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

38 extracted references · 36 canonical work pages

  1. [1]

    Lukas Alt, Anara Kozhokanova, Thomas Ilsche, Christian Terboven, and Matthias S. Mueller. An Experimental Setup to Evaluate RAPL Energy Counters for Heterogeneous Memory. In Proceedings of the 15th ACM/SPEC International Conference on Performance Engineering , pages 71–82, London United Kingdom, May 2024. ACM

    work page 2024

  2. [2]

    Lotaru: Locally predicting workflow task runtimes for resource management on heterogeneous infras- tructures

    Jonathan Bader, Fabian Lehmann, Lauritz Thamsen, Ulf Leser, and Odej Kao. Lotaru: Locally predicting workflow task runtimes for resource management on heterogeneous infras- tructures. Future Generation Computer Systems , 150:171–185, January 2024

    work page 2024

  3. [3]

    The Datacenter as a Computer

    Luiz Andr´ e Barroso, Urs H¨ olzle, and Parthasarathy Ranganathan. The Datacenter as a Computer. Springer US, third edition edition, 2018

    work page 2018

  4. [4]

    PowerMon 2: Fine- grained, Integrated Power Measurement

    Daniel Bedard, Robert Fowler, Min Yeol Lim, and Allan Porterfield. PowerMon 2: Fine- grained, Integrated Power Measurement

    work page

  5. [5]

    Kubernetes Scheduling: Taxonomy, Ongoing Issues and Challenges

    Carmen Carri´ on. Kubernetes Scheduling: Taxonomy, Ongoing Issues and Challenges. ACM Computing Surveys, 55(7):1–37, July 2023

    work page 2023

  6. [6]

    Estimating the Energy Footprint of Software Systems: a Primer, July 2024

    Fernando Castor. Estimating the Energy Footprint of Software Systems: a Primer, July 2024. arXiv:2407.11611 [cs]

    arXiv 2024

  7. [7]

    Hanebutte, Rahul Khanna, and Christian Le

    Howard David, Eugene Gorbatov, Ulf R. Hanebutte, Rahul Khanna, and Christian Le. RAPL: memory power estimation and capping. In Proceedings of the 16th ACM/IEEE international symposium on Low power electronics and design , pages 189–194, Austin Texas USA, August

    work page

  8. [8]

    Nextflow enables reproducible computational workflows

    Paolo Di Tommaso, Maria Chatzou, Evan W Floden, Pablo Prieto Barja, Emilio Palumbo, and Cedric Notredame. Nextflow enables reproducible computational workflows. Nature Biotechnology, 35(4):316–319, April 2017

    work page 2017

Show all 38 references
  1. [9]

    An Empirical Evaluation of the Energy and Performance Overhead of Monitoring Tools on Docker-Based Systems

    Madalina Dinga, Ivano Malavolta, Luca Giamattei, Antonio Guerriero, and Roberto Pietran- tuono. An Empirical Evaluation of the Energy and Performance Overhead of Monitoring Tools on Docker-Based Systems. In Flavia Monti, Stefanie Rinderle-Ma, Antonio Ruiz Cort´ es, Zibin 22 Zh...

  2. [10]

    Durillo, Hamid Mohammadi Fard, and Radu Prodan

    Juan J. Durillo, Hamid Mohammadi Fard, and Radu Prodan. MOHEFT: A multi-objective list-based method for workflow scheduling. In 4th IEEE International Conference on Cloud Computing Technology and Science Proceedings , pages 185–192, Taipei, Taiwan, December

  3. [11]

    Fellows Yates, Thiseas C

    James A. Fellows Yates, Thiseas C. Lamnidis, Maxime Borry, Aida Andrades Valtue˜ na, Zandra Fagern¨ as, Stephen Clayton, Maxime U. Garcia, Judith Neukamm, and Alexander Peltzer. Reproducible, portable, and efficient ancient genome reconstruction with nf-core/eager.PeerJ, 9:e10...

    2021

  4. [12]

    Blair, and Adrian Friday

    Charlotte Freitag, Mike Berners-Lee, Kelly Widdicks, Bran Knowles, Gordon S. Blair, and Adrian Friday. The real climate and transformative impact of ICT: A critique of estimates, trends, and regulations. Patterns, 2(9):100340, September 2021

    2021

  5. [13]

    DeepTheft: Stealing DNN Model Architectures through Power Side Channel, September 2023

    Yansong Gao, Huming Qiu, Zhi Zhang, Binghui Wang, Hua Ma, Alsharif Abuadbba, Minhui Xue, Anmin Fu, and Surya Nepal. DeepTheft: Stealing DNN Model Architectures through Power Side Channel, September 2023. arXiv:2309.11894 [cs]

    2023 arXiv

  6. [14]

    Examining the Challenges of Scientific Workflows

    Yolanda Gil, Ewa Deelman, Mark Ellisman, Thomas Fahringer, Geoffrey Fox, Dennis Gan- non, Carole Goble, Miron Livny, Luc Moreau, and Jim Myers. Examining the Challenges of Scientific Workflows. Computer, 40(12):24–32, December 2007

    2007

  7. [15]

    An Energy Efficiency Feature Survey of the Intel Haswell Processor

    Daniel Hackenberg, Robert Schone, Thomas Ilsche, Daniel Molka, Joseph Schuchart, and Robin Geyer. An Energy Efficiency Feature Survey of the Intel Haswell Processor. In 2015 IEEE International Parallel and Distributed Processing Symposium Workshop, pages 896–904, Hyderabad, In...

    2015

  8. [16]

    An experimental comparison of software-based power meters: focus on CPU and GPU

    Mathilde Jay, Vladimir Ostapenco, Laurent Lefevre, Denis Trystram, Anne-C´ ecile Orgerie, and Benjamin Fichel. An experimental comparison of software-based power meters: focus on CPU and GPU. In 2023 IEEE/ACM 23rd International Symposium on Cluster, Cloud and Internet Computin...

    2023

  9. [17]

    Rapid and accurate energy models through cal- ibration with IPMI and RAPL

    Richard Kavanagh and Karim Djemame. Rapid and accurate energy models through cal- ibration with IPMI and RAPL. Concurrency and Computation: Practice and Experience , 31(13):e5124, July 2019

    2019

  10. [18]

    Bi-Objective Optimization of Data-Parallel Applications on Heteroge- neous HPC Platforms for Performance and Energy Through Workload Distribution

    Hamidreza Khaleghzadeh, Muhammad Fahad, Arsalan Shahid, Ravi Reddy Manumachu, and Alexey Lastovetsky. Bi-Objective Optimization of Data-Parallel Applications on Heteroge- neous HPC Platforms for Performance and Energy Through Workload Distribution. IEEE Transactions on Paralle...

    2021

  11. [19]

    Nurminen, and Zhonghong Ou

    Kashif Nizam Khan, Mikael Hirki, Tapio Niemi, Jukka K. Nurminen, and Zhonghong Ou. RAPL in Action: Experiences in Using RAPL for Power Measurements. ACM Transactions on Modeling and Performance Evaluation of Computing Systems , 3(2):1–26, June 2018

    2018

  12. [20]

    Laros, Phil Pokorny, and David DeBonis

    James H. Laros, Phil Pokorny, and David DeBonis. PowerInsight - A commodity power measurement capability. In 2013 International Green Computing Conference Proceedings , pages 1–6, Arlington, VA, USA, June 2013. IEEE

    2013

  13. [21]

    Ponder: Online Prediction of Task Memory Requirements for Scientific Workflows

    Fabian Lehmann, Jonathan Bader, Ninon De Mecquenem, Xing Wang, Vasilis Bountris, Flo- rian Friederici, Ulf Leser, and Lauritz Thamsen. Ponder: Online Prediction of Task Memory Requirements for Scientific Workflows. In 2024 IEEE 20th International Conference on e- Science (e-Sc...

    2024 arXiv

  14. [22]

    Cost and Energy Aware Scheduling Algorithm for Scientific Workflows with Deadline Constraint in Clouds

    Zhongjin Li, Jidong Ge, Haiyang Hu, Wei Song, Hao Hu, and Bin Luo. Cost and Energy Aware Scheduling Algorithm for Scientific Workflows with Deadline Constraint in Clouds. IEEE Transactions on Services Computing , 11(4):713–726, July 2018

    2018

  15. [23]

    A Tax- onomy and Survey of Power Models and Power Modeling for Cloud Servers

    Weiwei Lin, Fang Shi, Wentai Wu, Keqin Li, Guangxin Wu, and Al-Alas Mohammed. A Tax- onomy and Survey of Power Models and Power Modeling for Cloud Servers. ACM Computing Surveys, 53(5):1–41, September 2021. 23

    2021

  16. [24]

    PLATYPUS: Software-based Power Side-Channel Attacks on x86

    Moritz Lipp, Andreas Kogler, David Oswald, Michael Schwarz, Catherine Easdon, Claudio Canella, and Daniel Gruss. PLATYPUS: Software-based Power Side-Channel Attacks on x86. In 2021 IEEE Symposium on Security and Privacy (SP) , pages 355–371, San Francisco, CA, USA, May 2021. IEEE

    2021

  17. [25]

    Scientific Work- flows: Business as Usual? In Umeshwar Dayal, Johann Eder, Jana Koehler, and Hajo A

    Bertram Lud¨ ascher, Mathias Weske, Timothy McPhillips, and Shawn Bowers. Scientific Work- flows: Business as Usual? In Umeshwar Dayal, Johann Eder, Jana Koehler, and Hajo A. Reijers, editors, Business Process Management , volume 5701, pages 31–47. Springer Berlin Heidelberg, ...

    2009

  18. [26]

    Hall, Christopher H

    Felix M¨ older, Kim Philipp Jablonski, Brice Letcher, Michael B. Hall, Christopher H. Tomkins- Tinch, Vanessa Sochat, Jan Forster, Soohyun Lee, Sven O. Twardziok, Alexander Kanitz, Andreas Wilm, Manuel Holtgrewe, Sven Rahmann, Sven Nahnsen, and Johannes K¨ oster. Sustainable d...

    2021

  19. [27]

    A Survey of Power and Energy Predictive Models in HPC Systems and Applications

    Kenneth O’brien, Ilia Pietri, Ravi Reddy, Alexey Lastovetsky, and Rizos Sakellariou. A Survey of Power and Energy Predictive Models in HPC Systems and Applications. ACM Computing Surveys, 50(3):1–38, May 2018

    2018

  20. [28]

    James Phung, Young Choon Lee, and Albert Y. Zomaya. Modeling System-Level Power Consumption Profiles Using RAPL. In 2018 IEEE 17th International Symposium on Network Computing and Applications (NCA) , pages 1–4, Cambridge, MA, November 2018. IEEE

    2018

  21. [29]

    Energy-Aware Workflow Scheduling Using Frequency Scaling

    Ilia Pietri and Rizos Sakellariou. Energy-Aware Workflow Scheduling Using Frequency Scaling. In 2014 43rd International Conference on Parallel Processing Workshops , pages 104–113, Minneapolis, MN, USA, September 2014. IEEE

    2014

  22. [30]

    An Introduction to Docker and Analysis of its Performance

    Babak Bashari Rad, Harrison John Bhatti, and Mohammad Ahmadi. An Introduction to Docker and Analysis of its Performance. 2017

    2017

  23. [31]

    Energy Efficiency Aspects of the AMD Zen 2 Architecture

    Robert Sch¨ one, Thomas Ilsche, Mario Bielert, Markus Velten, Markus Schmidl, and Daniel Hackenberg. Energy Efficiency Aspects of the AMD Zen 2 Architecture. In 2021 IEEE International Conference on Cluster Computing (CLUSTER), pages 562–571, September 2021. arXiv:2108.00808 [cs]

    2021 arXiv

  24. [32]

    Quality Assessment of GPU Power Pro- filing Mechanisms

    Satyabrata Sen, Neena Imam, and Chung-Hsing Hsu. Quality Assessment of GPU Power Pro- filing Mechanisms. In 2018 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW), pages 702–711, Vancouver, BC, May 2018. IEEE

    2018

  25. [33]

    A survey of Kubernetes scheduling algorithms

    Khaldoun Senjab, Sohail Abbas, Naveed Ahmed, and Atta Ur Rehman Khan. A survey of Kubernetes scheduling algorithms. Journal of Cloud Computing , 12(1):87, June 2023

    2023

  26. [34]

    Nextflow in Bioinformatics: Execu- tors Performance Comparison Using Genomics Data

    Vikt´ oria Spiˇ sakov´ a, Luk´ aˇ s Hejtm´ anek, and Jakub Hynˇ st. Nextflow in Bioinformatics: Execu- tors Performance Comparison Using Genomics Data. Future Generation Computer Systems , 142:328–339, May 2023

    2023

  27. [35]

    Assessing global Sentinel- 2 coverage dynamics and data availability for operational Earth observation (EO) applications using the EO-Compass

    Martin Sudmanns, Dirk Tiede, Hannah Augustin, and Stefan Lang. Assessing global Sentinel- 2 coverage dynamics and data availability for operational Earth observation (EO) applications using the EO-Compass. International Journal of Digital Earth , 13(7):768–784, July 2020

    2020

  28. [36]

    The Galaxy platform for accessible, reproducible and col- laborative biomedical analyses: 2022 update

    The Galaxy Community, Enis Afgan, Anton Nekrutenko, Bj´ orn A Gr¨ uning, Daniel Blanken- berg, Jeremy Goecks, Michael C Schatz, Alexander E Ostrovsky, Alexandru Mahmoud, Andrew J Lonie, Anna Syme, Anne Fouilloux, Anthony Bretaudeau, Anton Nekrutenko, Anup Kumar, Arthur C Esche...

    2022

  29. [37]

    Tanenbaum

    Maarten Van Steen and Andrew S. Tanenbaum. A brief introduction to distributed systems. Computing, 98(10):967–1009, October 2016. Appendix Figure 9: The bar chart shows the differences in the total amount of energy measured using a plugin, an additional workflow task and Prome...

    2016

  30. [196]

    Series Title: Lecture Notes in Computer Science

    Springer Nature Switzerland, Cham, 2023. Series Title: Lecture Notes in Computer Science

    2023

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.