KEcoLab

Quick Links

User Documentation

• User Guide

• Usage Scenario Script

• Access Result

Developer Documentation

• Project Structure

• CI/CD Pipeline

• Report Generation

• Contribution Guidelines

Introduction

The Remote Eco Lab project aims to provide a streamlined process for measuring software energy consumption remotely using a CI/CD pipeline. By automating the measurement process and integrating with the OSCAR tool, developers can make informed decisions to improve code efficiency and obtain software eco-certification with the Blue Angel. For further details on measuring the energy consumption of software, Use the links below to navigate to each section:

• Getting Started: Learn what KEcolab is, why it matters, and the differences between remote and manual testing processes.
• User Documentation: Detailed instructions for users on creating usage scenario scripts, submitting merge requests, and accessing test results.
• Developer Documentation: Information on project structure, CI/CD integration, and contribution guidelines.
• About Us: Background information on the project, contributors, contact details, and meeting notes.

Getting Started

What is KEcolab?

KEcolab is KDE’s dedicated platform for measuring the energy consumption of software remotely. Every piece of software we use operates on physical hardware that consumes energy—not only the energy used to charge our device but also the often-overlooked energy expenditures occurring in the background. KEcolab’s mission is to expose these hidden energy costs and provide users and developers with accurate and reliable data so they can optimize their software for better energy efficiency.

The Hidden Cost of Digital Technology

In our digital age, technology’s material footprint is often hidden by the compactness of devices and the “invisible” nature of the infrastructure (like data centers and underwater cables). Users underestimate the material footprint of digital technology due to this very nature. Every software application contributes to energy consumption because it runs on hardware that requires power—power that is generated using resources and often contributes to carbon emissions. As digital services become more ubiquitous, so does the cumulative energy consumption—and consequently, the environmental impact—grows, making sustainability a critical concern in software development.

Measuring the software

To support sustainable software development, a test lab was set up in Berlin to measure the energy consumption of software. Initially, developers had to send their software for on-site testing, which was slow and inefficient. To improve this, an automated system was introduced. Developers could now submit scripts through GitLab, which would run energy tests through an automated pipeline without needing to be on-site and analyze the results for accuracy and consistency. This streamlined process made energy measurements faster and more accessible, helping promote energy-efficient development practices and supporting sustainability goals.

User Documentation

Measuring an application's energy consumption isn’t as simple as just checking how much power your computer is using. There can be multiple different processes running simultaneously, consuming energy in some way or the other. So, to accurately measure the energy consumption of a certain application, it’s essential to recreate real-world user interactions of just that application in a controlled environment. This is done using Usage Scenario Scripts, a structured set of instructions that simulate different application states and user behaviours to get a clear picture of its power consumption. These scripts are executed multiple times to ensure that every test is performed consistently, eliminating variability that could affect energy measurement results.

But what are these instructions?

Before energy measurement begins, the exact instructions to be executed must be defined. These instructions are categorized into three key scripts:

1. Baseline Measurement Script - What’s the system doing when nothing is running?

Before we can measure how much power an application uses, we need a reference point—a baseline. This is just the system running without the application open. This script is executed first and provides a crucial comparison for later stages. Establishing this baseline isolates the energy consumption that is specifically due to the application, rather than the operating system or other processes running in the background.

2. Idle State Measurement Script - What happens when the app is open but you’re not using it?

The idle script measures the energy usage when the application is running but not actively being used. While this might seem like an unimportant scenario, applications often consume power even when sitting idle due to background tasks, UI rendering, and memory usage. This test helps identify whether an application is inefficient when idle. Ideally, applications should minimize energy consumption when not in use.

3. Standard Usage Scenario Script - Simulating how a real person uses the app

The standard usage script is the most comprehensive, simulating real-world interactions with the application. This script mimics how an actual user would navigate through and interact with the software, providing the most accurate picture of its energy consumption under typical use.

    The power meter records energy usage throughout the entire session, generating detailed data on power consumption during different operations;

Generating these Scripts

To create these scripts, you'll need an automation tool that can simulate user interactions without manual input. This ensures each test is performed consistently, providing accurate measurements. Some tools that can help with this are:

xdotool
A command-line tool for X11 that simulates keyboard input and mouse activity. It's powerful and widely used for automating tasks in Linux environments.

Actiona
A cross-platform automation tool that allows you to execute various actions on your computer, such as emulating mouse clicks, key presses, and more. It offers a simple editor and supports scripting for advanced customization.

kecotest
An automation tool designed for testing and automating tasks in KDE environments. It integrates well with KDE applications and provides a user-friendly interface for creating automation scripts.

These tools can help you automate the process of creating and running the scripts, post which it's important to organize them properly before submitting them for testing through a merge request on our Gitlab project.

Creating a Merge Request

Fork or clone the Remote Eco Lab repository to your GitLab account. Create a new branch in your fork/clone and add the usage scenario scripts in the path -
scripts/test_scripts/package_name/ (for example, scripts/test_scripts/org.kde.kate/log_sus.sh).
Push the changes and initiate a merge request, using the application package name as the title. For example, org.kde.kate.

Review and Approval

Sit back and relax while your proposed application is reviewed for any potential security risks.

Accessing the results:

The final Energy measurement report is available at Job Artifacts under the Result stage. Utilize the energy measurement report to analyze energy consumption of your software.

Developer Documentation

The test lab in berlin consists of -

• A test PC (System Under Test) to run emulation scripts,
• A power meter to measure the energy consumption of the test PC, and
• Another PC (Data Aggregator & Evaluator) to collect and analyze the output data.

Initially to access this facility, developers relied on individuals in Berlin to test software for them on-site. But now it can be accessed through a CI/CD pipeline that is automatically triggered once a merge request is approved in our Repository.

The merge request must contain three scripts—one for baseline measurement, one for idle mode, and one for standard usage scenarios—along with a configuration file. The energy usage results can be analyzed and summarized using OSCAR (Open Source Software Consumption Analysis in R). This also ensures that each test runs in the exact same environment, leading to more reliable and reproducible results.

The CI/CD pipeline is divided into three stages. The first stage involves installing the Flatpak on the lab computer, followed by the energy measurement stage where energy consumption is measured using a predefined process. Finally, in the last stage, the results are available as an artifact.