Pith. sign in

REVIEW 4 major objections 5 minor 29 references

Ecoscape: Fault Tolerance Benchmark for Adaptive Remediation Strategies in Real-Time Edge ML

T0 review · 4 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read This paper proposes Ecoscape, a benchmark that injects faults into Kubernetes and scores SLO violations so edge-machine-learning remediation strategies can be compared without a physical testbed.

desk verdict A useful open-source benchmark proposal for Kubernetes remediation strategies in edge ML, but the scoring formula as written contracts the accuracy SLO in the case study, and the evaluation lacks baselines, repetitions, and a real remediator. read the letter →

arxiv 2507.22702 v1 pith:Y5PZJQ47 submitted 2025-07-30 cs.PF

Hendrik Reiter , Ahmad Rzgar Hamid , Florian Schlösser , Mikkel Baun Kj{ae}rgaard , Wilhelm Hasselbring This is my paper · ORCID
classification cs.PF
keywords faulttolerancebenchmarkKubernetesedgecomputingmachinelearninginferenceremediationstrategieschaosengineeringSLOviolationscore
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

The paper tries to establish that remediation strategies for keeping edge machine-learning services within service level objectives can be compared fairly by running them in a simulated Kubernetes environment with injected faults and scoring SLO violations. The central claim is a new benchmark, Ecoscape, that turns each SLO into a normalized violation score and combines weighted scores into one number. A sympathetic reader would care because today there is no standard way to compare remediation actions such as rescheduling workloads or reducing model depth. If Ecoscape works, teams can evaluate the fault tolerance of edge-ML systems without a physical testbed and can tune SLO priorities to their domain.

What carries the argument

The load-bearing object is the weighted SLO violation score: for each SLO, the metric $\hat{V}_{\text{SLO}} = \frac{1}{|T|} \sum_{t=1}^{T} \left(1 - \frac{\tau}{v(t)}\right)$ when $v(t) > \tau$, otherwise zero, aggregated as $V_{\text{total}} = \sum_i w_i \cdot \hat{V}_{\text{SLO}_i}$. This score, inspired by autoscaling performance evaluation, turns SLO compliance into one number a remediator is graded against. Around it, the benchmark machinery is the pipeline that makes the score meaningful: JSON scenario definitions that become Kubernetes manifests, location labels that guide fault injection, Kafka-based load generation with event-time latency measurement, and Kepler for energy monitoring.

What would settle it

Run the same set of remediation strategies through Ecoscape and on a heterogeneous physical edge testbed using the same fault profiles; if the ranking of total violation scores differs, the simulated abstraction does not faithfully transfer. A cheaper check is to measure whether CPU stress injected into a Kubernetes node produces the same latency, accuracy, and energy signature as a resource-constrained edge device.

Watch

Extended reading notes

Core claim

Ecoscape's central claim is that a configurable, reproducible benchmark procedure can quantify how well a Kubernetes remediator maintains predefined service level objectives under injected faults. Declarative JSON configurations are translated into Kubernetes deployments, chaos-injection tools simulate network latency and CPU stress, and Prometheus and Kepler monitor latency, accuracy, and energy consumption. The resulting SLO violation score, computed as a normalized per-SLO violation aggregated by user-chosen weights, lets different remediation actions be compared on a single scale. In the object-recognition case study, two fault scenarios (CPU stress on edge nodes and increased network latency) produced total violation scores of 0.011 and 0.042 as the remediator restored SLO compliance through rescheduling and model-depth reduction.

Load-bearing premise

The load-bearing premise is that limiting CPU and memory in a Kubernetes pod and injecting stress with chaos tooling reproduces how a real edge device would behave, so scores measured in the cluster predict what a remediator would achieve on physical hardware.

Editorial extensions

If this is right

  • A Kubernetes remediator can be graded by one number instead of by ad hoc latency, accuracy, and energy logs, allowing direct comparison of strategies.
  • Because scenarios are declarative, benchmark runs are reproducible and configurable to domain-specific SLOs and weights.
  • Teams can evaluate remediation actions without physical edge hardware, lowering the entry barrier for fault-tolerance testing.
  • The case study suggests rescheduling and model-depth reduction are measurable responses to CPU stress and network latency faults, respectively.
  • Publishing the measured SLIs as a replication package means other remediators can be rerun against the same fault scenarios.

Reading between the lines

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

  • The paper leaves implicit that the same scoring scheme could be used online, not just offline: a remediator could pick the action with the lowest predicted violation score at runtime.
  • Because resource provisioning is modeled as an SLO, a natural extension is adding deployment cost or carbon footprint as weighted objectives, letting the weights encode business priorities.
  • The current benchmark covers performance-style faults; extending the chaos definitions to message loss and network partitioning would test whether the score remains discriminative under byzantine conditions.
  • A direct validation step the paper does not run is to compare Ecoscape's ranking of strategies with the ranking observed on a heterogeneous physical edge testbed under the same fault profiles.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. The paper introduces Ecoscape, a Kubernetes-based benchmark for evaluating remediation strategies in edge machine learning environments. The benchmark injects faults via Chaos Mesh, monitors SLOs via Prometheus and Kepler, and computes a weighted SLO violation score defined by Eqs. (1) and (2). The authors demonstrate the benchmark on an object-recognition case study with two fault scenarios (CPU stress and increased network latency), reporting SLO violation scores of 0.011 and 0.042. The stated goal is to provide a standardized, configurable method for comparing remediation strategies without a physical edge testbed.

Significance. If the central claim holds, Ecoscape would be a useful open-source tool for fair comparison of Kubernetes-based remediation strategies, a gap the paper argues is currently unfilled. Strengths include the public GitHub repository and Zenodo replication package, the explicit use of established components (Chaos Mesh, Prometheus, Kepler), and the simple, parameter-free scoring formula that is transparent and configurable. However, the paper's experimental evidence does not yet establish the benchmark's comparative power: it reports single runs of two scenarios, includes no no-remediation baseline and no alternative strategies, and uses a scoring formula that is inconsistent with one of its own SLO definitions. The physical-testbed fidelity limitation is acknowledged but not addressed with validation. These issues are load-bearing for the paper's main claim and require revision.

major comments (4)
  1. [Section IV, Eq. (1); Section V, SLO definitions] Eq. (1) assigns a positive violation score only when v(t) > tau, and the surrounding text states that SLOs must be formulated so that SLI values larger than the threshold indicate an SLO violation. The case study, however, defines the object-recognition accuracy SLO as 'must exceed 75%', i.e., the violation condition is v(t) < tau. If the raw accuracy ratio is fed into Eq. (1), accuracy violations contribute exactly zero and high accuracy contributes a positive penalty, so the reported total scores 0.011 and 0.042 are not reproducible from the stated formula. The implementation must either transform accuracy into an error rate with an inverted threshold or extend Eq. (1) to support a configurable violation direction; this must be documented and fixed.
  2. [Section V, Figures 2 and 3] The plotted quantity is not derived from Eq. (1). The y-axis is labelled 'Ratio of SLO violation' and includes values below zero (down to -0.6), but Eq. (1) is non-negative by construction. No definition of the plotted ratio, the 'slo baseline' line, or the three vertical red lines is provided beyond the qualitative descriptions in the text. Without a definition of the plotted quantity, the figures cannot be used to verify the reported scores or the claimed internal consistency in Section VI.
  3. [Section V and Section VI] The evaluation does not support the central comparative claim. Each scenario is presented as a single run with no repetitions, no confidence intervals, and no baseline run without remediation, and the two remediation actions are not compared against each other or against alternatives. Section VI also concedes that no autonomous remediator was used. Consequently, the claim that Ecoscape 'facilitates the comparative analysis of diverse actions' (Section I) is not demonstrated by the reported experiments; the paper needs repeated trials, a no-remediation control, and at least two alternative remediation strategies scored under identical conditions.
  4. [Section VI, feasibility of simulated testbed] The portability of scores from a Kubernetes cluster with Chaos Mesh injections to physical edge hardware is a load-bearing premise of the benchmark, since the stated goal is benchmarking 'without needing a physical edge testbed' (Abstract). The discussion only lists arguments for and against the abstraction. The paper should provide some validation evidence, such as a comparison of resource-limit and stress-ng behavior against a physical edge device, or a clearly stated threat-to-validity analysis; otherwise the benchmark score's predictive value for real edge deployments remains unsubstantiated.
minor comments (5)
  1. [Section IV, Eq. (2)] Specify whether the SLO weights are required to sum to 1; otherwise Vtotal is not bounded by 0 and 1 as claimed in the text.
  2. [Section V, SLO list] The accuracy SLO is defined as a percentage while latency and energy are defined as thresholds; define the SLI scale consistently so that Eq. (1) can be applied mechanically.
  3. [Section V, Figures 2 and 3] The three vertical red lines are described in the text but should be explicitly labeled in the captions (e.g., warm-up-to-evaluation, remediation start, reconfiguration completion).
  4. [Section VII] The phrase 'operating under under multiple SLOs' contains a duplicated word; remove the second 'under'.
  5. [Section II, related work] The description of Frisbee states that it 'does not provide quantitative performance metrics'; this claim should be substantiated with a citation to the Frisbee paper or softened, as it is used to motivate Ecoscape's scoring contribution.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: Ecoscape's score is a stated measurement convention, not a derived prediction; no fitted parameters or self-citation chain forces the results.

full rationale

The paper proposes a benchmark and defines a weighted SLO violation score (Eqs. 1-2) as a measurement convention. There is no fitted parameter that is later renamed as a prediction, and no quantity is defined in terms of the result it is supposed to establish. The case study injects faults and reports observed SLI traces; the scores (0.011 and 0.042) are arithmetic summaries of those traces, not outputs of a model trained on them. The self-citations ([11], [24], [29]) are motivational or definitional and are not load-bearing: [11] only motivates that reconfiguration actions affect SLO compliance, [24] supplies a standard benchmark definition, and [29] is a replication package. Section VI openly acknowledges limitations (no autonomous remediator, simulated instead of physical testbed, early maturity), but these are validity threats, not circular reductions. One non-circular correctness issue exists: Eq. 1 requires v(t) > tau for a violation, while the accuracy SLO is stated as 'must exceed 75%', so as written accuracy violations below threshold would score zero; this is an internal inconsistency/reproducibility bug, not an equivalence between input and output. Because no derivation chain reduces to its own assumptions, the circularity score is 0.

Assumptions & free parameters 3 free parameters · 4 assumptions · 1 invented entities

The central claim rests on plausible but unvalidated modeling assumptions: Kubernetes abstractions stand in for edge hardware, injected faults stand in for real fault processes, and user-chosen thresholds and weights define the score. None of these are fitted to data, and the paper flags the main hardware-fidelity concern itself. The artifact has two public external handles, code and SLI data.

free parameters (3)
  • SLO weights = latency 0.5, accuracy 0.25, energy 0.25
    Chosen by the authors to emphasize latency in the case study; they directly determine the total score in Eq. (2) and are not justified by data.
  • SLO thresholds = latency 2.5 s, accuracy 75%, energy 120 J
    Hand-selected targets for the object recognition scenario; they define violation in Eq. (1) and bound what the benchmark can conclude about other systems.
  • Phase timing = 15 s warm-up and chaos start, 30 s to remediator action, 15 s reconfiguration
    Ad hoc timing chosen for the case study; it determines which intervals are counted as violations.
assumptions (4)
  • domain assumption Kubernetes CPU/memory requests and limits faithfully emulate edge device resource availability.
    Invoked in Section VI to argue a physical testbed is unnecessary; the authors acknowledge the counterargument of hardware heterogeneity.
  • domain assumption Chaos Mesh network latency and stress-ng CPU stress represent realistic edge faults.
    Used in Section V to create the two fault scenarios; no evidence is given that these match real fault distributions or severities.
  • ad hoc to paper SLOs are formulated monotonically so that SLI values above the threshold indicate violation.
    Stated before Eq. (1) in Section IV; this restricts which objectives the benchmark can handle directly.
  • domain assumption Tasks are portable across all nodes and load is distributed among zones.
    Taken from the assumptions in Section III; workload rescheduling as a remediation action depends on this.
invented entities (1)
  • Ecoscape benchmark suite independent evidence
    purpose: Standardized fault-tolerance evaluation for Kubernetes remediation strategies in edge ML
    The paper introduces Ecoscape as a new software artifact; its public GitHub repository and Zenodo replication package provide an external handle to verify behavior.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Ecoscape: Fault Tolerance Benchmark for Adaptive Remediation Strategies in Real-Time Edge ML." pith.science (2026). https://pith.science/paper/Y5PZJQ47

@misc{pith2026250722702,
  author       = {Pith},
  title        = {Pith review of: Ecoscape: Fault Tolerance Benchmark for Adaptive Remediation Strategies in Real-Time Edge ML},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/Y5PZJQ47}},
  note         = {Machine review of arXiv:2507.22702}
}
read the original abstract

Edge computing offers significant advantages for realtime data processing tasks, such as object recognition, by reducing network latency and bandwidth usage. However, edge environments are susceptible to various types of fault. A remediator is an automated software component designed to adjust the configuration parameters of a software service dynamically. Its primary function is to maintain the services operational state within predefined Service Level Objectives by applying corrective actions in response to deviations from these objectives. Remediators can be implemented based on the Kubernetes container orchestration tool by implementing remediation strategies such as rescheduling or adjusting application parameters. However, currently, there is no method to compare these remediation strategies fairly. This paper introduces Ecoscape, a comprehensive benchmark designed to evaluate the performance of remediation strategies in fault-prone environments. Using Chaos Engineering techniques, Ecoscape simulates realistic fault scenarios and provides a quantifiable score to assess the efficacy of different remediation approaches. In addition, it is configurable to support domain-specific Service Level Objectives. We demonstrate the capabilities of Ecoscape in edge machine learning inference, offering a clear framework to optimize fault tolerance in these systems without needing a physical edge testbed.

Figures

Figures reproduced from arXiv: 2507.22702 by the authors.

Figure 1
Figure 1. Deployment of the object recognition service on a cloud node and [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Ratio of the SLIs compared to the SLOs in the scenario of CPU stress [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Ratio of the SLIs compared to the SLOs in the scenario of network [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

29 extracted references · 16 canonical work pages

  1. [1]

    Efficient privacy preserving data collection and computation offloading for fog-assisted iot,

    S. Chen, X. Zhu, H. Zhang, C. Zhao, G. Yang, and K. Wang, “Efficient privacy preserving data collection and computation offloading for fog-assisted iot,” IEEE Transactions on Sustainable Computing , vol. 5, no. 4, p. 526–540, Oct. 2020. [Online]. Available: http: //dx.doi.org/10.1109/TSUSC.2020.2968589

    arXiv 2020

  2. [2]

    Revisiting edge ai: Opportunities and challenges,

    T. Meuser, L. Loven, M. Bhuyan, S. G. Patil, S. Dustdar, A. Aral, S. Bayhan, C. Becker, E. D. Lara, A. Y . Ding, J. Edinger, J. Gross, N. Mohan, A. D. Pimentel, E. Riviere, H. Schulzrinne, P. Simoens, G. Solmaz, and M. Welzl, “Revisiting edge ai: Opportunities and challenges,” IEEE Internet Computing , vol. 28, pp. 49–59, 2024

    work page 2024

  3. [3]

    Machine learning in real-time internet of things (iot) systems: A survey,

    J. Bian, A. A. Arafat, H. Xiong, J. Li, L. Li, H. Chen, J. Wang, D. Dou, and Z. Guo, “Machine learning in real-time internet of things (iot) systems: A survey,” IEEE Internet of Things Journal , vol. 9, no. 11, p. 8364–8386, Jun. 2022. [Online]. Available: http://dx.doi.org/10.1109/JIOT.2022.3161050

    arXiv 2022

  4. [4]

    Pruning convolutional neural networks for resource efficient inference,

    P. Molchanov, S. Tyree, T. Karras, T. Aila, and J. Kautz, “Pruning convolutional neural networks for resource efficient inference,” 2016. [Online]. Available: https://arxiv.org/abs/1611.06440

    arXiv 2016

  5. [5]

    Compensated-dnn: energy efficient low-precision deep neural networks by compensating quantization errors,

    S. Jain, S. Venkataramani, V . Srinivasan, J. Choi, P. Chuang, and L. Chang, “Compensated-dnn: energy efficient low-precision deep neural networks by compensating quantization errors,” in Proceedings of the 55th Annual Design Automation Conference , ser. DAC ’18. ACM, Jun. 2018, p. 1–6. [Online]. Available: http://dx.doi.org/10.1145/3195970.3196012

    work page arXiv 2018

  6. [6]

    Conditional deep learning for energy-efficient and enhanced pattern recognition,

    P. Panda, A. Sengupta, and K. Roy, “Conditional deep learning for energy-efficient and enhanced pattern recognition,” in Proceedings of the 2016 Conference on Design, Automation & Test in Europe , ser. DATE ’16. San Jose, CA, USA: EDA Consortium, 2016, p. 475–480

    work page 2016

  7. [7]

    A survey of faults and fault- injection techniques in edge computing systems,

    M. Pourreza and P. Narasimhan, “A survey of faults and fault- injection techniques in edge computing systems,” in 2023 IEEE International Conference on Edge Computing and Communications (EDGE). IEEE, Jul. 2023, p. 63–71. [Online]. Available: http: //dx.doi.org/10.1109/EDGE60047.2023.00021

    arXiv 2023

  8. [8]

    A survey of autoscaling in kubernetes,

    M.-N. Tran, D.-D. Vu, and Y . Kim, “A survey of autoscaling in kubernetes,” in 2022 Thirteenth International Conference on Ubiquitous and Future Networks (ICUFN) . IEEE, Jul. 2022. [Online]. Available: http://dx.doi.org/10.1109/ICUFN55119.2022.9829572

    arXiv 2022

Show all 29 references
  1. [9]

    A survey of kubernetes scheduling algorithms,

    K. Senjab, S. Abbas, N. Ahmed, and A. u. R. Khan, “A survey of kubernetes scheduling algorithms,” Journal of Cloud Computing, vol. 12, no. 1, Jun. 2023. [Online]. Available: http: //dx.doi.org/10.1186/s13677-023-00471-1

    2023 doi

  2. [10]

    Custom scheduling in kubernetes: A survey on common problems and solution approaches,

    Z. Rejiba and J. Chamanara, “Custom scheduling in kubernetes: A survey on common problems and solution approaches,” ACM Computing Surveys , vol. 55, no. 7, p. 1–37, Dec. 2022. [Online]. Available: http://dx.doi.org/10.1145/3544788

    2022 doi

  3. [11]

    Investigating quality attributes of machine learning inference on the edge-cloud continuum,

    A. R. Hamid, H. Reiter, M. B. Kjærgaard, and W. Hasselbring, “Investigating quality attributes of machine learning inference on the edge-cloud continuum,” Softwaretechnik-Trends, vol. 45, no. 1, Novem- ber 2024, proceeddings 15th Symposium on Software Performance. [Online]. Av...

    2024

  4. [12]

    Frisbee: A suite for benchmarking systems recovery,

    F. Nikolaidis, A. Chazapis, M. Marazakis, and A. Bilas, “Frisbee: A suite for benchmarking systems recovery,” in Proceedings of the 1st Workshop on High Availability and Observability of Cloud Systems , ser. EuroSys ’21. ACM, Apr. 2021, p. 18–24. [Online]. Available: http://dx...

    2021

  5. [13]

    Kalka and T

    W. Kalka and T. Szydlo, µChaos: Moving Chaos Engineering to IoT Devices. Springer Nature Switzerland, 2024, p. 239–254. [Online]. Available: http://dx.doi.org/10.1007/978-3-031-63783-4 18

    2024 doi

  6. [14]

    Edgecloudsim: An environment for performance evaluation of edge computing systems,

    C. Sonmez, A. Ozgovde, and C. Ersoy, “Edgecloudsim: An environment for performance evaluation of edge computing systems,” in 2017 Second International Conference on F og and Mobile Edge Computing (FMEC) . IEEE, May 2017. [Online]. Available: http://dx.doi.org/10.1109/FMEC.2017.7946405

    2017

  7. [15]

    Cloud continuum: The definition,

    S. Moreschini, F. Pecorelli, X. Li, S. Naz, D. Hastbacka, and D. Taibi, “Cloud continuum: The definition,” IEEE Access , vol. 10, p. 131876–131886, 2022. [Online]. Available: http://dx.doi.org/10.1109/ ACCESS.2022.3229185

    2022

  8. [16]

    Defog: fog computing benchmarks,

    J. McChesney, N. Wang, A. Tanwer, E. de Lara, and B. Varghese, “Defog: fog computing benchmarks,” in Proceedings of the 4th ACM/IEEE Symposium on Edge Computing , ser. SEC ’19. ACM, Nov. 2019, p. 47–58. [Online]. Available: http://dx.doi.org/10.1145/3318216. 3363299

    2019 doi

  9. [17]

    Kfiml: Kubernetes-based fog computing iot platform for online machine learning,

    Z. Wan, Z. Zhang, R. Yin, and G. Yu, “Kfiml: Kubernetes-based fog computing iot platform for online machine learning,” IEEE Internet of Things Journal , vol. 9, no. 19, p. 19463–19476, Oct. 2022. [Online]. Available: http://dx.doi.org/10.1109/JIOT.2022.3168085

    2022

  10. [18]

    Towards network-aware resource provisioning in kubernetes for fog computing applications,

    J. Santos, T. Wauters, B. V olckaert, and F. De Turck, “Towards network-aware resource provisioning in kubernetes for fog computing applications,” in 2019 IEEE Conference on Network Softwarization (NetSoft). IEEE, Jun. 2019, p. 351–359. [Online]. Available: http://dx.doi.org/1...

    2019

  11. [19]

    Latency-aware industrial fog application orchestration with kubernetes,

    R. Eidenbenz, Y .-A. Pignolet, and A. Ryser, “Latency-aware industrial fog application orchestration with kubernetes,” in 2020 Fifth International Conference on F og and Mobile Edge Computing (FMEC). IEEE, Apr. 2020, p. 164–171. [Online]. Available: http://dx.doi.org/10.1109/F...

    2020

  12. [20]

    Optimal workload allocation in fog-cloud computing towards balanced delay and power consumption,

    R. Deng, R. Lu, C. Lai, T. H. Luan, and H. Liang, “Optimal workload allocation in fog-cloud computing towards balanced delay and power consumption,” IEEE Internet of Things Journal , p. 1–1, 2016. [Online]. Available: http://dx.doi.org/10.1109/JIOT.2016.2565516

    2016

  13. [21]

    A survey of online failure prediction methods,

    F. Salfner, M. Lenk, and M. Malek, “A survey of online failure prediction methods,” ACM Computing Surveys , vol. 42, no. 3, p. 1–42, Mar. 2010. [Online]. Available: http://dx.doi.org/10.1145/1670679.1670680

    2010

  14. [22]

    Chaos engineering: A multi-vocal literature review,

    J. Owotogbe, I. Kumara, W.-J. V . D. Heuvel, and D. A. Tamburri, “Chaos engineering: A multi-vocal literature review,” 2024. [Online]. Available: https://arxiv.org/abs/2412.01416

    2024 arXiv

  15. [23]

    Service level agreement in cloud computing: Taxonomy, prospects, and challenges,

    F. Qazi, D. Kwak, F. G. Khan, F. Ali, and S. U. Khan, “Service level agreement in cloud computing: Taxonomy, prospects, and challenges,” Internet of Things , vol. 25, p. 101126, Apr. 2024. [Online]. Available: http://dx.doi.org/10.1016/j.iot.2024.101126

    2024

  16. [24]

    Benchmarking as empirical standard in software engineering research,

    W. Hasselbring, “Benchmarking as empirical standard in software engineering research,” in Evaluation and Assessment in Software Engineering, ser. EASE 2021. ACM, Jun. 2021, p. 365–372. [Online]. Available: http://dx.doi.org/10.1145/3463274.3463361

    2021

  17. [25]

    Autoscaler evaluation and configuration: A practitioner’s guideline,

    M. Straesser, S. Eismann, J. von Kistowski, A. Bauer, and S. Kounev, “Autoscaler evaluation and configuration: A practitioner’s guideline,” in Proceedings of the 2023 ACM/SPEC International Conference on Performance Engineering, ser. ICPE ’23. ACM, Apr. 2023, p. 31–41. [Online...

    2023

  18. [26]

    Process-Based Efficient Power Level Exporter,

    M. Amaral, H. Chen, T. Chiba, R. Nakazawa, S. Choochotkaew, E. K. Lee, and T. Eilam, “Process-Based Efficient Power Level Exporter,” IEEE International Conference on Cloud Computing, CLOUD , pp. 456– 467, 2024

    2024

  19. [27]

    Imagenet: A large-scale hierarchical image database,

    J. Deng, W. Dong, R. Socher, L.-J. Li, K. Li, and L. Fei-Fei, “Imagenet: A large-scale hierarchical image database,” in 2009 IEEE Conference on Computer Vision and Pattern Recognition . IEEE, Jun. 2009. [Online]. Available: http://dx.doi.org/10.1109/CVPR.2009.5206848

    2009

  20. [28]

    Benchmarking distributed stream data processing systems,

    J. Karimov, T. Rabl, A. Katsifodimos, R. Samarev, H. Heiskanen, and V . Markl, “Benchmarking distributed stream data processing systems,” in 2018 IEEE 34th International Conference on Data Engineering (ICDE) . IEEE, Apr. 2018. [Online]. Available: http: //dx.doi.org/10.1109/IC...

    2018

  21. [29]

    Ecoscape slis,

    H. Reiter and A. R. Hamid, “Ecoscape slis,” 2025. [Online]. Available: https://zenodo.org/doi/10.5281/zenodo.15170211

    2025 doi

Pith tools

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