Cooperative vs. non-cooperative marketplace for
computing jobs to be run on geo-distributed data
centers only supplied by renewable energies

Georges da Costa, Atom Deutsch-Filippi, Igor Fontana de Nardin, Jean-Marc Nicod, Veronika Rehn-Sonigo, Patricia Stolf

Nicod, Veronika Rehn-Sonigo, Patricia Stolf

<figure><img src="image_1.png" /></figure>

To cite this version:

Georges da Costa, Atom Deutsch-Filippi, Igor Fontana de Nardin, Jean-Marc Nicod, Veronika Rehn-Sonigo, et al.. Cooperative vs. non-cooperative marketplace for computing jobs to be run on geo-distributed data centers only supplied by renewable energies. Cluster Computing, 2025, 28 (10), pp.637. 10.1007/s10586-025-05300-5 . hal-05239473

HAL Id: hal-05239473

https://hal.science/hal-05239473v1

Submitted on 4 Sep 2025

**HAL** is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>
# Cooperative vs. non-cooperative marketplace for computing jobs to be run on geo-distributed data centers only supplied by renewable energies

Georges Da Costa<fnref n="1" /> · Atom Deutsch-Filippi<fnref n="1" /> · Igor Fontana de Nardin<fnref n="1" /> · Jean-Marc Nicod<fnref n="2" /> · Veronika Rehn-Sonigo<fnref n="2" /> · Patricia Stolf<fnref n="1" />

Received: 30 September 2024 / Revised: 7 April 2025 / Accepted: 24 April 2025
© The Author(s) 2025

## Abstract

Since the Paris Agreement, there has been increased focus on decreasing greenhouse gas (GHG) emissions related to power supply. Data centers are a huge energy consumer sector due to their continuous operational demand. A way to reduce their impact on GHG is by using renewable energy in their power supply. However, renewable energy introduces production intermittence since it depends on the climate conditions. Geo-distributed data centers can exploit diverse climate conditions to diminish the problem. This work presents a geo-distributed data center marketplace only supplied by renewable energies. In our marketplace model, the data centers are independent and compete for the users' jobs. The winner data center is defined using a reverse auction process. We compare different aspects, such as centralized/distributed architectures and cooperative/non-cooperative marketplaces. Our results show that the cooperative and distributed data center model earns more money (5.39% more money), wastes less energy (3.81% less energy), and provides higher QoS (improvement of 4.31% for services and 2.71% for tasks).

**Keywords** Cloud computing · Marketplace · Auction · Renewable energy

## 1 Introduction

One of the biggest challenges of our generation is Global warming. Recent reports predict a warming of 2.6 to 2.9° C by 2100 (compared to the pre-industrial era temperatures),

well above the 1.5° C defined by the Paris Agreement [1–3]. Achieving 1.5° C demands a world engagement, mainly reducing greenhouse gas (GHG) emissions. GHG is generated during the combustion process of fossil fuel, one of the world main sources of energy production [4]. GHG stays in the atmosphere, creating a layer as a blanket over the planet surface. Without this blanket, the Earth can balance the radiation energy from the sun and the thermal radiation from the Earth to space [5]. However, this human-generated blanket imposes a barrier to the thermal radiation from the Earth, heating the planet. One significant GHG emitter is the Information and Communications Technology (ICT) sector, producing around 1.8–2.8 % of the world total GHG [6]. Part of these emissions are linked to the energy consumption. ICT includes all elements of cloud computing, such as user computers, network devices, and data centers [7].

In the past years, we had an increase in internet and data center demand [8]. Comparing 2015 to 2022, the number of internet users increased by 78 % (3 billion to 5.3 billion), the internet traffic increased by 600 % (0.6 Zettabyte to 4.4 Zettabytes), and data center workloads increased by

<figure><img src="image_3.png" /></figure>

Patricia Stolf

patricia.stolf@irit.fr

Georges Da Costa

georges.da-costa@irit.fr

Igor Fontana de Nardin

igor fontana@irit.fr

Jean-Marc Nicod

Jean-Marc.Nicod@ens2m.fr

Veronika Rehn-Sonigo

veronika.sonigo@univ-fcomte.fr

<footnote>The authors are ordered in alphabetical order of their surnames.</footnote>

<footnote n="1">1 IRIT, Université de Toulouse, CNRS, Toulouse, France</footnote>

<footnote n="2">2 FEMTO-ST institute, Université de Bourgogne Franche-Comté, CNRS, UFC, ENSMM, Besançon, France</footnote>
+340 % (180 million to 800 million) [8]. The problem tends to grow due to emerging technologies such as streaming, cloud gaming, artificial intelligence, and machine learning. A way to reduce the GHG emissions of energy consumption is by using renewable energy to power the cloud data centers [4, 9–11]. Renewable energy generates energy from natural sources, such as solar, wind, geothermal, hydropower, wave and tidal, and biomass [10]. However, the biggest challenge of implementing Renewable Energy Sources (RES) is its intermittent power production since it is weather-dependent. A way to diminish the intermittency problem is by spreading data centers in different locations, taking advantage of diverse climate conditions.

In this context, this article proposes a marketplace with independent geo-distributed data centers operated by only renewable energies. Figure 1 illustrates the main idea of this marketplace. Our marketplace model is data center provider agnostic, meaning it considers the data centers as black boxes, not knowing the providers’ state (e.g., load or energy available) to make decisions. The idea behind this model is to propose a way for different data center providers (Amazon, Google, OVHCloud, etc) to cooperate by executing jobs from the users. Considering the data centers as black boxes makes it impossible to do a global optimization (e.g., choosing the data center with the lowest load). This kind of optimization is well studied with multiple publications, but it demands a complete knowledge of every data center state [12–14]. Our model works at the allocation level, meaning we focus on choosing the data center to run the jobs and not the scheduling and execution inside the data centers. We consider that all data centers inside the model passed by a business selection process, and they are all suitable to run the jobs with quality and

safety. Even if in reality each data center has its own parameters and algorithms, we focus on a model without considering these particularities.

In addition, we assume that all data center providers are only powered by local renewable sources. Considering the data center emissions, it is mandatory to start thinking of solutions considering this scenario (even if currently, this is not the case). Big data center providers buy green electricity from third-party power providers, receiving RECS (Renewable Energy Certificate System) certificates. Doing this helps renewable energy production indirectly by investing in this kind of production and increasing the publicity. However, it is impossible to know the exact production source they receive since the power grid is mixed. In addition, they transfer the challenges of renewable energy production (such as intermittence) to these third parties. For example, in a peak of demand, the providers will use more energy, independently of the production source. Another use case is the implementation of data centers in regions without a power grid. These remote locations can be good for placing the data centers without impacting the power grid.

This renewable-only assumption can be seen as extreme. Even so, some other works, such as Datazero, go in this direction [15]. Datazero project proposes a centralized renewable-only data center. Our objective with this assumption is to evaluate the impact of the cooperative marketplace considering renewable sources. Therefore, if our approach works well in a renewable-only scenario, extending it to a mixed approach (grid and renewable) is simple. Since we make the marketplace model data center agnostic, there is no need to change it to a mixed approach.

To increase the availability of our data centers, we assume that they are geo-distributed, that is they are at different places in the world. This distribution increases the availability of resources, because as the production of renewable energies such as sun and wind depends on geographical position, geo-distributed data centers mechanically increases the periods when resources are available to respond to requests at the level of the entire data center infrastructure. Taking back Fig. 1, the users send their jobs to a centralized marketplace, the only centralized element of our model. Each independent data center evaluates the job requirements and its load to calculate the price relevant to its own economical model (while respecting the user price boundaries). This model can be seen as a reverse auction process since the sellers bid to execute the jobs from the buyers. This reversion is crucial because only the data centers know their availability and capacity. However, this can lead to non-cooperative behaviors, where some data centers reduce their bid value aggressively to receive more money. This aggressive

<figure><img src="image_4.png" /><figcaption>**Fig. 1** Centralized marketplace with distributed data centers example. Each data center proposes a price (their bid) for the job to run on their infrastructure</figcaption></figure>

<figure><img src="image_5.png" /></figure>
behavior makes the other data centers starve, reducing their earned money and increasing their wasted energy.

The contributions of the paper are:

1. We present an agnostic model for independent data center providers to cooperate considering that they use renewable energy only;

2. We propose two ways to solve the problem. First, we implemented a mix integer linear program (MILP). However, this MILP takes too long to solve as its complexity increases. Therefore, we propose a heuristic to find a solution in a reasonable time. We compare both solutions using simulation;

3. We compare different behaviors through extensive experimental campaigns. First, we evaluate the benefits of the geo-distributed approach compared to a centralized data center. Then, we compare the non-cooperative approach with the cooperative one, showing the advantages of the latter.

This paper is organized as follows. Section 2 presents the related work, highlighting the gap in the state-of-the-art. Then, Sect. 3 shows an overview of the problem. Section 4 addresses the proposed model. After that, Sect. 5 details the proposed heuristic to solve the problem in a reasonable time. Section 6 presents the experimental environment, and Sect. 7 discusses the results of all experimental campaigns. Finally, Sect. 8 concludes the article.

## 2 Related work

In the literature, the usage of renewable energy in geo-distributed data centers is well-studied but using the grid as backup and making global optimization. Some articles focus on a distributed data center of the same operator [12–14, 16, 17]. A centralized scheduler can find the optimal place to run a job, considering the load of each data center, the power production from renewable sources, and the price of the grid power. Other works introduce cooperation for independent data centers from different operators [18–20]. Their cooperation comes to buy energy for the power grid using a demand-response approach. The idea is to coordinate to achieve better prices. Therefore, the data centers do not share their workload nor use only renewable sources. In our model, we have a cooperation in terms of job execution.

Some works studied the idea of applying an auction process in the cloud user and provider relationship [21]. Considering single-sided auctions (where only buyers or sellers can place bids), forward auction models are the most common types [21]. In a forward auction model, the competition occurs on the user side since they bid for the

available resources. Amazon EC2 Spot market is an example of a forward auction model.

In [22], the authors propose an auction-based virtual machine scheduling model. The users submit the virtual machine (VM) requirements using a bidding language created by the authors. The objective is to satisfy the maximal set of bids maximizing the cloud provider's profit, considering the energy costs of the physical servers. Therefore, this work uses a forward auction, ignoring geo-distributed data centers and energy production from renewable sources. The authors in [23] described a Renewable-Aware Load Balancing with geo-distributed data centers under different electricity markets. In this context, a load balancer has complete knowledge of the different data centers' status, such as electricity price, actual load, maximal load possible, etc. Their objective is to use more renewable energy to reduce global electrical costs. So, they do not have an auction process in their solution. Similarly, [9] proposes four uncertainty-aware scheduling algorithms for geo-distributed data centers. The idea is to include the uncertainty of user requests, cloud providers, and power production in the scheduling decision. Their objectives are to minimize the overall cost and maximize the available renewable energy usage. However, this work includes non-renewable energy as backup and they do not use an auction process in their solution.

[24] proposes a geo-distributed data center, grouping them by region. The authors proposed two architectures: Hierarchical and Distributed IaaS Provisioning. In the hierarchical architecture, a central element works as the auctioneer in a double-side auction (both buyers and sellers place bids). The idea is to find which region will win the users' requests, finding a match between the prices of the region (given by the electrical price, for example) and the bid from the user. In the distributed architecture, the users send their requests to the data centers in their region. When a region can not deal with the request, a (reverse) single-side auction, where the other regions bid for this request. They do not include renewable energy directly in their problem. In [25], the authors proposed a dynamic online double-sided auction mechanism for price scheduling and resource allocation in the cloud. The double-sided auction comes from the idea where the users send their bid value, and the cloud providers ask for some value. The problem is to find a match between both sides. This work focuses on the economic aspects of the auction process, ignoring the electrical side of the cloud providers.

The authors of [26] also presented a double-sided auction process for effective resource utilization in cloud computing. They modeled the problem as a linear integer programming model to maximize the profit received by the cloud resource providers. The users define the price that they are willing to pay, and the resource providers indicate
the price that they are willing to sell the resources. In this model, they do not consider the electrical prices and renewable energy usage. [27] defined a VM single-sided forward auction for batch jobs. Thus, the cloud users bid to run their batch jobs in the cloud. The cloud provider does not necessarily have to schedule the job upon acceptance and does not have to execute it continuously in every time slot. However, these jobs have to be finished before a hard deadline. The objective is to maximize social welfare, which considers the cloud provider's revenue and the user's utility. This work does not consider any energy-related aspect.

In [28], the authors proposed a single-sided forward auction, where the users bid for the VMs with determined types. The data centers are geographically distributed, but the authors do not consider the electrical aspects. Similarly to [27], the objective is to maximize social welfare (provider's revenue and the user's utility). The authors of [29] created a single-sided reverse auction process. The users define the maximum acceptable price, and the cloud providers (non-renewable) bid for the user tasks. They execute several rounds, changing the user and provider prices until an agreement or a maximum round is achieved. For the allocation problem, they defined a multi-objective optimization problem, solved using Immune Evolutionary Algorithm. The objective of this problem is to maximize the market efficiency, user satisfaction, and the quality of the service. They integrated the three metrics into a weighted function.

We believe that reverse auction is crucial to renewable- only and geo-distributed data centers. We consider geo- distributed data centers from different providers. There- fore, they do not share internal information, such as machine load and power production. Since they are the only ones knowing their status, they are the only ones that can know the possibility of running a job and with which quality. Consequently, they are the best actors to decide in a shared marketplace. Additionally, we suppose that to reduce data center emissions through renewable energy usage, geo-distribution and cooperation are crucial. For these reasons, we believe in a solution that combines renewable-only, geo-distribution, and reverse auction pro- cess. Therefore, to the best of our knowledge, no work proposes a cooperative reverse auction-like marketplace using independent and geo-distributed data centers pow- ered only by renewable energy. In addition, no work pro- poses a comparison between centralized and distributed nor an impact analysis of non-cooperative behaviors in this renewable-only environment.

## 3 Problem statement

Taking back Fig. 1, users send their jobs to a centralized marketplace. Each user submits the minimum and maximum acceptable prices for each job, whether it is a task or a service. The data centers attending in the marketplace to execute these jobs are located in different parts of the world. Usually, the user takes the main role in the auction process in this kind of marketplace, bidding for the available resources. On the contrary, we propose the exact reverse auction process, letting the data centers bid for the jobs [30]. The main reason for applying the reverse auction is that each data center is independent and does not share its state. In other words, the model considers each data center as a black box.

In this paper, the time horizon $\mathcal{H}$ is discretized into $K$ time slots of duration $\Delta t$ such that a job execution is divided into an integer number of time slots. If a job is submitted at time $d$ such that $(k-1)\Delta t < d \le k\Delta t$ (i.e., during the time slot number $k-1$, time slots being num- bered from 0 to $K-1$), it can start at earliest at the beginning of time slot $k$. Therefore, an auction process starts each new time slot $k$ with all available jobs arrived no later than time slot $k-1$. So, at each time slot $k$, the marketplace announces each job from the queue. Then, the distributed data centers bid for the jobs using a bid value. A bid value is the minimum price that the data center accepts to earn when starting the job at the beginning of the current time slot $k$ (jobs submitted no later than the previous time slot). The price therefore corresponds to the amount the user is willing to pay to get the job completed on time. A discrete function defines this price. The latter is equally distributed from the minimum to the maximum accept- able prices, named market price. This market price depends on the time slot when the job is bid. Thus, the price must be less than or equal to the market price, and the bid value must be less than or equal to the price. Note that a job can be either a task or a service. Tasks are considered to be batch jobs that require resources over a certain period of time to perform a large computation process (e.g., image processing). On the other hand, services are interactive jobs that must respond to user requests (e.g., web service). Then, according to its type (task or service), the market price of the job varies. Figure 2 shows the market price for the two types of job.

The set of jobs consists in a set of services $\mathcal{S}$ and a set of tasks $\mathcal{T}$. For each submitted task, the user also sends the total amount of computation required (percentage of core usage if proceed in one time slot). This can be seen as the number of vCPUs demanded by the user. For example, suppose a task requires a total computation of 150 % of one data center capacity core in one time slot. In this case,
Price and penalty system for task $T_j \in \mathcal{T}$

<figure><img src="image_6.png" /></figure>

Price and penalty system for service $S_i \in S$

<figure><img src="image_7.png" /><figcaption>Fig. 2 Price and penalty models for the tasks and services in the marketplace</figcaption></figure>

the task can be executed as follows: one time slot with 100 % utilization of the IT resource, and 50 % in the next time slot. All other options for distributing this workload are possible, e.g., six time slot of 25 % each, etc. Depending the execution schedule (start time and duration before the completion time), a price is associated to each task when completed. To help the computation of this market price of each task $T_j \in \mathcal{T}$, an arrival time $rt_j$ (release date or first time slot in which the task is available to the auction process, its submission having been made a time slot before), a due date $ddt_j$ (soft deadline and last time slot for ideal task completion), and a deadline $ddlt$ (hard deadline and last time slot for task completion, otherwise the task is killed at the beginning of the time slot $ddlt_j + 1$) are also known.

Figure 2 shows how this price $mpt_j(k)$ can be evaluated considering the values that define the task, the date when the bid is done. For instance, at the release date $rt_j$, the market price of the task $T_j$ is the minimum price ($pmt_j$) that the user is able to pay to proceed the task. Thus, ideally the user expects his job to be completed by the due date $ddt_j$ with a market price at most equal to $pMt_j$. This is why the market price increases as we get closer to the due date (the green points in Fig. 2). Therefore, it is possible to calculate

the market price $mpt_j(k)$ for any bid at time slot $k$ between the release date $rt_j$ and due date $ddt_j$ using Eq. 1:

$$mpt_j(k) = \begin{cases} 0, & \text{if } k < rt_j \\ pmt_j + (pMt_j - \\ pmt_j) \frac{k - rt_j}{ddt_j - rt_j}, & \text{if } rt_j \le k \le ddt_j \\ 0, & \text{if } ddt_j < k \end{cases} \quad (1)$$

where $k$ is the bid time slot for a task $T_j$, $pmt_j$ the minimum price given by the user, $pMt_j$ the maximum price, $rt_j$ the task availability time slot, and $ddt_j$ the due date. The data centers cannot bid on a task after its due date. Besides the market price, Fig. 2 presents another concept: the penalty. Considering a given task $T_j$, a penalty is given to the data center in charge of the computation of $T_j$ if it does not meet the required Quality of Service (QoS) criteria. The penalty depends on the finish time of the task. We consider the finish time to be the first time slot where all the job computations have been completed. As mentioned before, this data center can split the $T_j$ amount of work. Nevertheless, the data center has to finish the task early to avoid the penalty. Three possible penalties for tasks exist: (1) finished until the due date, (2) between the due date and deadline, or (3) after the deadline. No penalty is applied if the task is completed before or on the due date. A linear function defines the penalty if the task finishes between the due date and the deadline. The user that submits the $T_j$, indicates the minimum and maximum penalties (resp. $pnltmt_j$ and $pnltMt_j$), which are applied to create the following penalty $pnltdlt_j(k)$ (Equation (2)):

$$pnltdlt_j(k) = \begin{cases} 0, & \text{if } k \le ddt_j \\ pnltmt_j + (pnltMt_j - \\ pnltmt_j)\left(\frac{k - ddt_j}{ddlt_j - ddt_j}\right), & \text{if } ddt_j < k \le ddt_j \\ pnldlt_j, & \text{if } ddt_j < k \end{cases} \quad (2)$$

where $k$ is the time slot when $T_j$ is completed, $ddt_j$ the due date, and $ddlt_j$ the deadline. Finally, if the task finishes after the deadline, it receives the deadline penalty (also defined by the user). This deadline penalty is greater than the maximum penalty $pnltMt_j$ and the maximum price. It is therefore in the interest of the data centers to complete the task as soon as possible to maximize the money earned ($mp_j(k) - pnltdlt_j(k)$). Therefore, the batch task penalty is related to the moment when the task result is given to the user.

The second job type is the services, in which the user defines the fixed start and end time slots. The data center cannot change these time slots. For example, suppose we
have a service that starts at time slot 4 and ends at time slot 8. So, it will execute on time slots 4, 5, 6, and 7. The service workload is the CPU load for every time slot between start and end. Taking the same example, a workload of 0.60, 0.70, 0.20, 0.50 means that at time slot 4 the load is 60 %, time slot 5 is 70 %, time slot 6 is 20 %, and time slot 7 is 50 %. Regarding the service *market price mps*<sub>*i*</sub>(*k*), it is similar to the task linear function. However, instead of the due date, we use the start time as the time slot when the price is the maximum:

$$ mps_i(k) = \begin{cases} 0 & \text{if } k < rs_i \\ pms_i + (pMs_i - pms_i) \frac{k - rs_i}{ss_i - rs_i} & \text{if } rs_i \le k \le ss_i \\ 0 & \text{if } ss_i < k \end{cases} \quad (3) $$

The service *penalty pnlts*<sub>*i*</sub>(*k*) is computed using the difference between the demanded and executed load, which is called degradation. Figure 2 exemplifies this *penalty (pnlts*<sub>*i*</sub> in red). In this case, the user defines a unique *penalty value (pnlts*<sub>*i*</sub>) that is applied to the load difference. It can be calculated as follows:

$$ pnlts_i(k) = pnlts_i \times \left(1 - \frac{\alpha s_i(k)}{ws_i(k)}\right) \quad (4) $$

where *k* is every time slot when the service is executed, *pnlts*<sub>*i*</sub>(*k*) is the penalty given to the degradation at time slot *k*, *αs*<sub>*i*</sub>(*k*) is the workload done at time slot *k*, and *ws*<sub>*i*</sub>(*k*) is the workload demanded at time slot *k*. For example, suppose we have a service has a demand of 60 % at a time slot, but the data center only gives 30 %. So, the data center receives half of the service *penalty (pnlts*<sub>*i*</sub>) in this slot. The service total *penalty* is given by the sum of the *penalties pnlts*<sub>*i*</sub>(*k*) in every time slot. Therefore, it is possible to execute less work for services, which can result in higher latency in answering the user's requests, for example.

Coming back to Fig. 1, each data center estimates the possible *gain* received for each job. At the auction process moment, the *bid value* minus an estimated *penalty* gives the estimated *gain*. The data centers predict the *penalty* using their actual load and the predicted renewable energy production (it can estimate when it finishes a task or how much it degrades the service). They cannot use more energy than the renewable energy production. Then, the data center can vary *bid value* according to how much they accept to reduce the *gain*, going from the *market price* (maximum) to the *penalty* (minimum). *Bid value* cannot be lower than the *penalty* because it would give a negative *gain*. After all data centers send their *bid value*, the centralized marketplace gives the job to the data center with the lowest *bid value*.

Since the data centers have the freedom to choose their *bid value*, this can lead to non-cooperative behaviors. For example, a data center can reduce its *bid value* too much (being aggressive), accepting to receive less money and winning more jobs than the other data centers. Globally, this non-cooperative behavior makes the other data centers receive less money, wasting their energy production. In addition, this aggressive data center can provide lower QoS since it will be overcharged. In a cooperative system, all data centers apply the same bidding rules. For example, they can always agree to bid *marketprice* – *gain*. This policy gives the job to the data center with higher *gain*. Also, if a data center is overcharged, the estimated *penalty* increases and the *gain* reduces. Therefore, this cooperative policy can lead to a natural load balancing.

One of our objectives is to compare a centralized and distributed marketplace, highlighting that spreading the data centers in different locations can increase the availability. However, we also provide an analysis of the impact of cooperative and non-cooperative behaviors in the marketplace. The idea is to show that a cooperative marketplace can make everyone receive more money and provide better QoS. But before diving into the experiments, the next section describes the model applied to solve this marketplace problem.

# 4 Models

This section introduces the different needed models to describe the problem formally. Table 1 presents all notations for this section. Let $\mathcal{H} = K\Delta t$ denote a time horizon discretized into $K$ identical time slots of duration $\Delta t$ units of time. Let $k \in [0, K-1]$ be defined as both the $(k+1)$th time slot at instant $k\Delta t$ from the beginning of $\mathcal{H}$, i.e., $k=0$ designs the first time slot of $\mathcal{H}$. The global notations concerning the platform, workload, market, and mathematical models are given in the following sections.

## 4.1 Platform model

The platform is organized as a set of independent and distributed data centers, each with its own renewable power envelope that allows it to perform tasks and services submitted into a shared marketplace when allocated after the auction phase. The platform consists of a set of *n* data centers $\mathcal{DC} = \{\mathcal{DC}^0, \mathcal{DC}^1, \dots, \mathcal{DC}^{n-1}\}$. Let $Pre^d = \{Pre_k^d: 0 \le k < K\}$ be the power envelope available at each time slot *k* of $\mathcal{H}$ for each data center $\mathcal{DC}^d$ ($0 \le d < D$). The data center $\mathcal{DC}^d$ is not able to consume more than $Pre_k^d$ at each time slot *k*. Each data center $\mathcal{DC}^d$ consists of a set $\mathcal{C}^d = \{C^{d,c}: 0 \le c < nc^d\}$ of $nc^d$ cores to perform tasks and
<table><caption>**Table 1** Notations</caption><thead><tr><th>Variable</th><th>Description</th><th>Type</th><th>Input</th><th>Output</th></tr></thead><tbody><tr><td colspan="5"><strong>Time definition</strong></td></tr><tr><td>H</td><td>a given time window</td><td>Float</td><td>✓</td><td></td></tr><tr><td>Δt</td><td>duration of a time slot [u.t.]</td><td>Float</td><td>✓</td><td></td></tr><tr><td>K</td><td>number of time slots within H</td><td>Integer</td><td>✓</td><td></td></tr><tr><td>k</td><td>(k + 1)th time slot, 0 ≤ k &lt; K</td><td>Integer</td><td>✓</td><td></td></tr><tr><td colspan="5"><strong>Platform definition</strong></td></tr><tr><td>DC</td><td>set of D data centers</td><td>-</td><td>✓</td><td></td></tr><tr><td>D</td><td>Number of data centers within DC</td><td>Integer</td><td>✓</td><td></td></tr><tr><td>DC<sup>d</sup></td><td>data center d (DC<sup>d</sup> ∈ DC) with 0 ≤ d &lt; D</td><td>-</td><td>✓</td><td></td></tr><tr><td>nc<sup>d</sup></td><td>number of cores of data center DC<sup>d</sup></td><td>Integer</td><td>✓</td><td></td></tr><tr><td>Pre<sup>d</sup></td><td>available renewable power envelope of DC<sup>d</sup> over the time horizon H</td><td>List[Float]</td><td>✓</td><td></td></tr><tr><td>Pre<sup>d</sup><sub>k</sub></td><td>available power for DC<sup>d</sup> during the time slot k</td><td>Float</td><td>✓</td><td></td></tr><tr><td>C<sup>d</sup></td><td>set of cores of DC<sup>d</sup>, nc<sup>d</sup> = |C<sup>d</sup>|</td><td>-</td><td>✓</td><td></td></tr><tr><td>C<sup>d,c</sup></td><td>core c of DC<sup>d</sup> (C<sup>d,c</sup> ∈ C<sup>d</sup>), 0 ≤ c &lt; nc<sup>d</sup></td><td>-</td><td>✓</td><td></td></tr><tr><td>Pstat<sup>d,c</sup></td><td>static power needed to run one idle core</td><td>Float</td><td>✓</td><td></td></tr><tr><td>Pdyn<sup>d,c</sup></td><td>dynamic power needed to run one task on one core</td><td>Float</td><td>✓</td><td></td></tr><tr><td>W</td><td>the submitted workload (W = S ∪ T)</td><td>-</td><td>✓</td><td></td></tr><tr><td>on<sup>d,c</sup><sub>k</sub></td><td>equals 1 if core C<sup>d,c</sup> is switched on during time slot k, 0 otherwise</td><td>Boolean</td><td></td><td>✓</td></tr><tr><td colspan="5"><strong>Services</strong></td></tr><tr><td>S</td><td>set of I services S<sub>i</sub></td><td>-</td><td>✓</td><td></td></tr><tr><td>rs<sub>i</sub></td><td>S<sub>i</sub> release date</td><td>Integer</td><td>✓</td><td></td></tr><tr><td>ss<sub>i</sub></td><td>S<sub>i</sub> start time</td><td>Integer</td><td>✓</td><td></td></tr><tr><td>fs<sub>i</sub></td><td>S<sub>i</sub> finish time (start time ss<sub>i</sub> + length of workload ws<sub>i,k</sub>)</td><td>Integer</td><td>✓</td><td></td></tr><tr><td>ws<sub>i,k</sub></td><td>percentage of work demanded at time slot k by Service S<sub>i</sub></td><td>Float</td><td>✓</td><td></td></tr><tr><td>pms<sub>i</sub></td><td>minimum price of S<sub>i</sub></td><td>Float</td><td>✓</td><td></td></tr><tr><td>pMs<sub>i</sub></td><td>maximum price of S<sub>i</sub></td><td>Float</td><td>✓</td><td></td></tr><tr><td>pnlts<sub>i</sub></td><td>penalty for S<sub>i</sub> when degraded</td><td>Float</td><td>✓</td><td></td></tr><tr><td>pnlts<sub>i</sub>(k)</td><td>penalty for S<sub>i</sub> depending on time slot k</td><td>Float</td><td></td><td>✓</td></tr><tr><td>es<sup>d,c</sup><sub>i</sub></td><td>equals 1 if service S<sub>i</sub> is executed on C<sup>d,c</sup>, 0 otherwise</td><td>Boolean</td><td></td><td>✓</td></tr><tr><td>αs<sup>d,c</sup><sub>i,k</sub></td><td>percentage of work of service S<sub>i</sub> executed on C<sup>d,c</sup> during time slot k</td><td>Float</td><td></td><td>✓</td></tr><tr><td>bids<sup>d</sup><sub>i,k</sub></td><td>equals 1 if service S<sub>i</sub> is bid at slot k in dc d, 0 otherwise</td><td>Boolean</td><td></td><td>✓</td></tr><tr><td>pnlts<sup>d</sup><sub>i</sub></td><td>penalty of service S<sub>i</sub> for data center d</td><td>Float</td><td></td><td>✓</td></tr><tr><td>pnlts<sup>d</sup><sub>i</sub></td><td>penalty's of service S<sub>i</sub> for every data center d</td><td>Float</td><td></td><td>✓</td></tr><tr><td>pnlts<sup>d</sup><sub>i</sub></td><td>penalty's of service S<sub>i</sub> to exclude from data center d</td><td>Float</td><td></td><td>✓</td></tr><tr><td>gs<sup>d</sup><sub>i</sub></td><td>money gained of service S<sub>i</sub> for data center d</td><td>Float</td><td></td><td>✓</td></tr><tr><td colspan="5"><strong>Tasks</strong></td></tr><tr><td>T</td><td>set of J tasks T<sub>j</sub></td><td>-</td><td>✓</td><td></td></tr><tr><td>rt<sub>j</sub></td><td>T<sub>j</sub> release date</td><td>Integer</td><td>✓</td><td></td></tr><tr><td>ddt<sub>j</sub></td><td>T<sub>j</sub> due date</td><td>Integer</td><td>✓</td><td></td></tr><tr><td>dlt<sub>j</sub></td><td>T<sub>j</sub> deadline</td><td>Integer</td><td>✓</td><td></td></tr><tr><td>w<sub>j</sub></td><td>percentage total of work demanded by task T<sub>j</sub></td><td>Float</td><td>✓</td><td></td></tr><tr><td>pmt<sub>j</sub></td><td>minimum price of T<sub>j</sub></td><td>Float</td><td>✓</td><td></td></tr><tr><td>pMt<sub>j</sub></td><td>maximum price of T<sub>j</sub></td><td>Float</td><td>✓</td><td></td></tr><tr><td>pmt<sub>j</sub>(k)</td><td>market price of T<sub>j</sub></td><td>Float</td><td></td><td>✓</td></tr><tr><td>pnltmt<sub>j</sub></td><td>minimum penalty for T<sub>j</sub></td><td>Float</td><td>✓</td><td></td></tr><tr><td>pnltMt<sub>j</sub></td><td>maximum penalty for T<sub>j</sub></td><td>Float</td><td>✓</td><td></td></tr></tbody></table>
<table><caption>**Table 1 (continued)**</caption><thead><tr><th>Variable</th><th>Description</th><th>Type</th><th>Input</th><th>Output</th></tr></thead><tbody><tr><td>pnltdlt<sub>j</sub></td><td>penalty for T<sub>j</sub> when not completed before its deadline dlt<sub>j</sub></td><td>Float</td><td>✓</td><td></td></tr><tr><td>pnltdlt<sub>j</sub>(k)</td><td>penalty for T<sub>j</sub> depending on time slot k</td><td>Float</td><td></td><td>✓</td></tr><tr><td>e<sup>d,c</sup><sub>j</sub></td><td>equals 1 if task T<sub>j</sub> is executed on C<sup>d,c</sup>, 0 otherwise</td><td>Boolean</td><td></td><td>✓</td></tr><tr><td>αt<sup>d,c</sup><sub>j,k</sub></td><td>percentage of work of task T<sub>j</sub> executed on C<sup>d,c</sup> during time slot k</td><td>Float</td><td></td><td>✓</td></tr><tr><td>bid<sup>d</sup><sub>j,k</sub></td><td>equals 1 if task T<sub>j</sub> is bid at slot k in dc d, 0 otherwise</td><td>Boolean</td><td></td><td>✓</td></tr><tr><td>αtf<sup>d</sup><sub>j,k</sub></td><td>percentage of the workload finished by task j at slot k in dc d</td><td>Float</td><td></td><td>✓</td></tr><tr><td>tf<sup>d</sup><sub>j,k</sub></td><td>equals 1 if task T<sub>j</sub> is finished at slot k in dc d, 0 otherwise</td><td>Boolean</td><td></td><td>✓</td></tr><tr><td>tff<sup>d</sup><sub>j,k</sub></td><td>equals 1 if slot k is the first slot where task T<sub>j</sub> is finished in dc d, 0 otherwise</td><td>Boolean</td><td></td><td>✓</td></tr><tr><td>pnltt<sup>d</sup><sub>j</sub></td><td>penalty of task T<sub>j</sub> for data center d when it does not complete tasks before deadline</td><td>Float</td><td></td><td>✓</td></tr><tr><td>gt<sup>d</sup><sub>j</sub></td><td>money gained of task T<sub>j</sub> for data center d</td><td>Float</td><td></td><td>✓</td></tr></tbody></table>

services when allocated. An idle core $C^{d,c}$ consumes a power of $Pstat^{d,c}$ when switched on, and each task or service consumes an additional power $Pdyn^{d,c}$ when allocated on $C^{d,c}$.

## 4.2 Workload model

The main objective of each independent data center $DC^d$ is to process a submitted workload $W$. This workload is composed of independent jobs, some of which are services $S$ and others are tasks $T$. Let $S = \{S_i : 0 \le i < I\}$ be the set of $I$ services and $T = \{T_j : 0 \le j < J\}$ be the set of $J$ tasks. Both services and tasks are submitted to the platform, where each data center $DC^d$ can bid. The main difference between services and tasks is related to the execution flexibility. Services have a fixed start and finish time. However, the data centers can reduce the amount of CPU allocated to each service, degrading the service QoS. A service $S_i$ is defined by its release date $rs_i$, its start time $ss_i$, its finished time $fs_i$, and its demanded work $ws_{i,k}$ with $rs_i \le ss_i$ with $0 \le i < I$. To illustrate the service execution, we suppose that a data center is running a service with start time $ss_i = 2$ and the loads $ws_{i,2} = 0.6$ (or 60 %) and $ws_{i,3} = 0.4$ (or 40 %). The load corresponds to the CPU usage of one core of one data center. That means that at time slot $k = 2$, the data center needs to allocate 60 % of its core capacity to this service, and 40 % at time slot $k = 3$. Any reduction (degradation) in these values results in penalties.

Differently of services, the tasks have a flexible execution time, but the data center must execute its workload completely. A task $T_j$ is defined by its release date $rt_j$, its

due date $ddt_j$, its deadline $dlt_j$, its percentage total of work $wt_j$. Note also that obviously $rt_j \le ddt_j \le dlt_j$ with $0 \le j < J$. All the defined dates are time slot numbers that start at the beginning of the corresponding time interval. To illustrate task execution, let's assume that a data center is running a task with release date $rt_j = 1$, due date $ddt_j = 5$, deadline $dlt_j = 8$, and percentage total of work $wt_j = 2$ (or 200 %). The percentage total of work corresponds to the CPU usage of one core of one data center. In our model, this work is flexible. Therefore, the data center can spread the work of a task as it wants. Let's say that it executes 50 % at time slot $k = 2$, 100 % at time slot $k = 3$, and 50 % at time slot $k = 4$. This means that, at time slot $k = 5$, the workload is entirely executed (sum of execution = 200 %). For the tasks, the degradation comes from the moment when the task finishes. If it finishes before or equal to the due date, there is no degradation (the case of the example). The degradation starts after the due date and linearly increases from the due date to the deadline. Finally, it has the maximal degradation when it finishes after the deadline.

## 4.3 Market model

As mentioned before, the marketplace centralizes where services and tasks are submitted to be performed by any data center in the platform. A decision has to be taken to select the appropriate data center, considering either a cooperation or a non-cooperation paradigm. The decision-making in this context demands economic data for each service or task. This economic data drives the data center auction process. Therefore, we add these useful data to complete the overall model by a market model. Every service $i$ ($0 \le i < I$) is composed of a maximum and a
minimum price $pMs_i$ and $pms_i$ ($pms_i \le pMs_i$) and a penalty $pnlts_i$. The service penalty is given to the data center according to the difference between workload executed and demanded. This penalty means a service can receive less CPU than demanded, resulting in a higher response time. For the tasks, their payoff is between $pmt_j$ and $pMs_i$, and the penalty is between the lower bound $pnltmt_j$ and an upper bound $pnltMt$. The penalty is applied when the completion time of a task is delayed beyond the due date but before the deadline $dlt_j$. Thereafter, the penalty is $pnltdlt_j$. Note that for $0 \le j < J$, $pmt_j \le pMt_j$ and $pnltmt_j \le pnltMt_j \le pnltdlt_j$.

## 4.4 Mathematical model

After describing the generic models, we create a linear mathematical model, allowing us to find an optimal solution for our problem. The main objective is maximizing the overall economic payoff of the distributed green data center platform. To make this possible, we need to define many constraints to respect the rules of the game. We also define useful variables to compute the economic payoff for each data center. This model works using a cooperative system. The following sections present the constraints and variables needed.

### 4.4.1 Constraints

Constraints on data centers Firstly, only one core can execute the services and tasks since no migration is allowed. Once a core c on data center d starts a service $S_i$ ($0 \le i < I$) or a task $T_j$ ($0 \le j < J$), this job cannot migrate to another core or another data center. Equations (5) and (6) ensure that only one core will run each service/task.

$$ \forall S_i \in S: \sum_{d=0}^{D-1} \sum_{c=0}^{nc^d-1} es_i^{d,c} \le 1 \quad (5) $$

$$ \forall T_j \in T: \sum_{d=0}^{D-1} \sum_{c=0}^{nc^d-1} et_j^{d,c} \le 1 \quad (6) $$

Then, Equation (7) delimits the load of each service. For each service, the model receives the start time ($ss_i$) and the load to execute in each time slot ($ws_{i,k}$). Then, the executed load ($\alpha s_{i,k}^{d,c}$) must be lesser or equal to $ws_{i,k}$ for each time slot $k$ between the start $ss_i$ and the finish $fs_i$. Since the services have a fixed start and finish time, all the workload before the start time and equal or after the finish time must be zero.

$$ \forall d, c, S_i \in S, k: \alpha s_{i,k}^{d,c} = \begin{cases} = 0 & \text{if } 0 \le k < ss_i \\ \le ws_{i,k} & \text{if } ss_i \le k < fs_i \\ = 0 & \text{if } fs_i \le k < K \end{cases} \quad (7) $$

Regarding the tasks, Equation (8) indicates that the task cannot start before its arrival. Then, Equation (9) spreads the workload into the future time slots (from $rt_j$ until the end $K$). The sum of the task $\alpha t_{j,k}^{d,c}$ must be lesser or equal to the task workload $wt_j$.

$$ \forall T_j \in T, 0 \le k < rt_j - 1: \alpha t_{j,k}^{d,c} = 0 \quad (8) $$

$$ \forall T_j \in T: \sum_{d=0}^{D-1} \sum_{c=0}^{nc^d-1} \sum_{k=rt_j}^{K-1} \alpha t_{j,k}^{d,c} \le wt_j \quad (9) $$

Since this model does not consider multi-core service/task and migration, only the core allocated to the tasks and services can run them. Equations (10) and (11) allow only the allocated core to have $\alpha > 0$. For the services, Equation (10) lets $\alpha s_{i,k}^{d,c} > 0$ only if $es_i^{d,c} = 1$. A service can execute less than the workload given. On the other hand, Equation (11) indicates that the core that executes the task ($et_j^{d,c} = 1$) must finish all the task workload ($\sum_{k=0}^{K} \alpha t_{j,k}^{d,c} / wt_j = 1$).

$$ \forall d, c, S_i \in S, k: \alpha s_{i,k}^{d,c} \le es_i^{d,c} \quad (10) $$

$$ \forall d, c, T_j \in T: \frac{\sum_{k=0}^{K} \alpha t_{j,k}^{d,c}}{wt_j} = et_j^{d,c} \quad (11) $$

Each data center $DC^d \in DC$ cannot consume more than the available power envelope $Pre_k^d$ at each time slot $k$ ($0 \le k < K$). Equation (12) assures it. This constraint calculates the power consumption considering the static ($Pstat^{d,c}$), if the server is on ($on_k^{d,c}$), and the dynamic power ($Pdyn^{d,c}$), which depends on the core load ($\sum_{S_i \in S} \alpha s_{i,k}^{d,c} + \sum_{T_j \in T} \alpha t_{j,k}^{d,c}$).

$$ \forall d, k: \sum_{c=0}^{nc^d-1} \left( Pstat^{d,c} \times on_k^{d,c} + Pdyn^{d,c} \left( \sum_{S_i \in S} \alpha s_{i,k}^{d,c} + \sum_{T_j \in T} \alpha t_{j,k}^{d,c} \right) \right) \le Pre_k^d \quad (12) $$

Moreover, for each time slot $k$ ($0 \le k < K$) and for each data center $DC^d \in DC$, tasks and services running on the core $C^{d,c}$ consume at most 100 % of the CPU capacity of the core (see Equation (13)). Finally, Equation (14) makes sure that a core $C^{d,c}$ is switched on at time slot $k$ if a task or a service is running on it.
$$ \forall d, c, k : \sum_{S_i \in S} \alpha s_{i,k}^{d,c} + \sum_{T_j \in T} \alpha t_{j,k}^{d,c} \le 1 \quad (13) $$

$$ \forall d, c, k : \sum_{S_i \in S} \alpha s_{i,k}^{d,c} + \sum_{T_j \in T} \alpha t_{j,k}^{d,c} \le on_k^{d,c} \quad (14) $$

Constraints on bidding Regarding the auction process, we must define the moments when it is possible to bid on a job (a service or a task). A job can only be bid after its arrival. So, Equations (15) and (16) indicate that the bid variables for services and tasks are equal to zero before their arrival.

$$ \forall d, S_i \in S, 0 \le k < rs_i : bids_{i,k}^d = 0 \quad (15) $$

$$ \forall d, T_j \in T, 0 \le k < rt_j : bidt_{j,k}^d = 0 \quad (16) $$

In addition, Equation (17) does not allow a bid after the service starting time. For the tasks, Equation (18) guarantees that the job bid must be before its due date.

$$ \forall d, S_i \in S, ss_i + 1 \le k < K : bids_{i,k}^d = 0 \quad (17) $$

$$ \forall d, T_j \in T, ddt_j + 1 \le k < K : bidt_{j,k}^d = 0 \quad (18) $$

Finally, we can have only one bid time slot in the data center that will execute the job. Equations (19) and (20) assure this constraint.

$$ \forall d, S_i \in S : \sum_{c=0}^{nc^d-1} es_i^{d,c} = \sum_{k=0}^{K-1} bids_{i,k}^d \quad (19) $$

$$ \forall d, T_j \in T : \sum_{c=0}^{nc^d-1} et_j^{d,c} = \sum_{k=0}^{K-1} bidt_{j,k}^d \quad (20) $$

Because tasks have a flexible start time, they need additional constraints compared to services. The tasks can only run in or after its bid time slot k where $bidt_{j,k}^d = 1$. Therefore, we introduce the constraint (21). This constraint verifies, for each time slot k, if the task is bid before this time slot (using $k'$ for previous time slots). If the task j is bid before k, $\sum_{k'=0}^k bidt_{j,k'}^d = 1$ and $\alpha t_{j,k}^{d,c}$ can be any value between 0 and 1. If not, $\sum_{k'=0}^k bidt_{j,k'}^d = 0$ and $\alpha t_{j,k}^{d,c}$ must be zero for all cores.

$$ \forall d, T_j \in T, k : \sum_{k'=0}^{k} bidt_{j,k'}^d \ge \sum_{c=0}^{nc^d-1} \alpha t_{j,k}^{d,c} \quad (21) $$

Constraints on task deadline violation The task penalty depends on the moment when the task finishes. So, we must discover at which time slot the task is completed. Thus, we first calculate how much work is finished in each time slot in Constraint (22). To do so, we sum $\alpha t_{j,k}^{d,c}$ from all previous time slots (using $k'$) and all cores of each data center. Then, we divide it by the total workload. When $\alpha t_{j,k}^{d,c} = 1$, it means that the task is finished in time slot k.

$$ \forall d, T_j \in T, k : \alpha tf_{j,k}^d = \frac{\sum_{k'=0}^{k-1} \sum_{c=0}^{nc^d-1} \alpha t_{j,k}^{d,c}}{wt_j} \quad (22) $$

Then, we need to define the time slots where the task $T_j$ is finished, using Constraints (23) and (24). In Constraint (23), for any $\alpha tf_{j,k}^d$ lesser than 1, $tf_{j,k}^d$ must be 0. $tf_{j,k}^d$ can be 1 only when $\alpha tf_{j,k}^d = 1$. However, $tf_{j,k}^d$ can also be 0 for a $\alpha tf_{j,k}^d = 1$, but we solve this problem later (using Constraint (25)). Constraint (24) guarantees that once $tf_{j,k}^d = 1$, all the following time slots will also be 1.

$$ \forall d, T_j \in T, k : (1 - tf_{j,k}^d) \ge (1 - \alpha tf_{j,k}^d) \quad (23) $$

$$ \forall d, T_j \in T, 1 \le k < K : tf_{j,k}^d \ge tf_{j,k-1}^d \quad (24) $$

After discovering the time slots where the task is finished, we must find the first time slot k where $tf_{j,k}^d = 1$. Then, we introduce Constraint (25) to set to 1 the variable $tff_{j,k}^d$ in the first time slot k where the task is finished. Since the task cannot be finished at time slot 0 (since it would demand task execution before time slot 0), we force $tff_{j,0}^d = 0$. We calculate the change value from time slot k and the previous time slot k - 1 for the values inside our time window $\mathcal{H}$ ($1 \le k < K$). For example, if variable $tf_{j,k}^d$ in both k and k - 1 is 0, $tff_{j,k}^d$ will be also 0. When both are 1, $tff_{j,k}^d$ will still be 0. Only when the variable $tf_{j,k}^d$ is 1 in k and 0 in k - 1, $tff_{j,k}^d$ will be 1. There is no case where k is 0 and k - 1 is 1 due to Constraint (24). Finally, the last term of Constraint (25) solves the problem of Constraint (23) not setting $tf_{j,k}^d$ to 1 when the task is completed. We introduce one time slot after the end of the time window in the variable $tff_{j,k}^d$, letting it be 1 when the data center executes this task ($et_j^{d,c}$), but $tf_{j,k}^d = 0$ in each time slot k ($0 \le k < K$). In this case, $tff_{j,K}^d$ will be 1 and it pays the penalty of the deadline (the highest penalty possible). Therefore, the objective (from Sect. 4.4.4) forces Constraint (23) to set $tf_{j,k}^d = 1$ as soon as possible, reducing the penalty.

$$ \forall d, T_j \in T, 0 \le k \le K : tff_{j,k}^d = \begin{cases} 0 & \text{if } k = 0 \\ tf_{j,k}^d - tf_{j,k-1}^d & \text{if } 1 \le k < K \\ (\sum_{c=0}^{nc^d-1} et_j^{d,c}) - tf_{j,K-1}^d & \text{if } k = K \end{cases} \quad (25) $$

### 4.4.2 Penalties

A penalty has to be paid by every data center that does not respect the QoS, i.e., not completing a task before its deadline or degrading the service. We calculate the penalties for tasks and services separately. Equation (26)
shows how to compute the penalty issued when task $T_j$ finishes after the due date. This equation contains two parts. The first part ($\sum_{k=dlt_j+1}^K tff_{j,k}^d \times pnltdlt_j$) is the penalty given to the data center if the job $j$ finishes after the deadline. The second part calculates the linear penalty for the job $j$ if it finishes between the time slot after the due date and the deadline.

$$ \forall d, T_j \in \mathcal{T} : pnlt_{j}^{d} = \left( \left( \sum_{k=dlt_j+1}^{K} tff_{j,k}^{d} \times pnltdlt_j \right) + \left( \sum_{k=dlt_j+1}^{K} tff_{j,k}^{d} \times (pnltmt_j + ((pnltMt_j - pnltmt_j) \times \frac{k-dlt_j}{dlt_j-dtt_j})) \right) \right) \quad (26) $$

Regarding the services, it is more complicated to keep the penalty linear since it depends on two variables ($\alpha s_{i,k}^{d,c}$ and $es_{i,k}^{d,c}$). To keep the model linear, we first calculate the penalty for every DC (even the ones that do not bid this service) using Equation (27). The data centers that do not execute the job have $\alpha s_{i,k}^{d,c} = 0$, receiving the maximal penalty in $pnltsd_i^d$. To solve it, we introduce Constraint (28), which puts the maximal service penalty on $pnltsr_i^d$ for the cores that do not execute the job. Finally, the final service $S_i$ penalty is given by Equation (29), which removes the penalty $pnltsr_i^d$ from penalty $pnltsd_i^d$ (remaining only the real penalty).

$$ \forall d, S_i \in \mathcal{S} : pnltsd_i^d = pnlts_i \times \left( \sum_{k=ss_i}^{fs_i} \sum_{c=0}^{nc^d-1} \left( 1 - \frac{\alpha s_{i,k}^{d,c}}{ws_{i,k}} \right) \right) \quad (27) $$

$$ \forall d, S_i \in \mathcal{S} : pnltsr_i^d = \sum_{k=ss_i}^{fs_i} pnlts_i \times (nc^d - \sum_{c=0}^{nc^d-1} es_{i,k}^{d,c}) \quad (28) $$

$$ pnltsd_i^d = pnltsd_i^d - pnltsr_i^d \quad (29) $$

### 4.4.3 Data center gain

Data centers win money each time they execute tasks or services for clients on which they succeeded in the auction process. The money gained with services is given by Constraint (30). Similarly, Constraint (31) calculates the money gained by the tasks.

$$ \forall d, S_i \in \mathcal{S} : gs_i^d = \sum_{k=0}^{K-1} bids_{i,k}^d \times \left( pms_i + \left( (pMs_i - pms_i) \times \frac{k - rs_i}{ss_i - rs_i} \right) \right) \quad (30) $$

$$ \forall d, T_j \in \mathcal{T} : gt_j^d = \sum_{k=0}^{K-1} bid_{j,k}^d \times \left( pmt_j + \left( (pMt_j - pmt_j) \times \frac{k - rt_j}{dlt_j - rt_j} \right) \right) \quad (31) $$

### 4.4.4 Objectives

Finally, the objective is to maximize the total benefits given by the money gained by the bid process minus the penalty of the impact on the jobs QoS. Equation (32) presents this objective.

$$ \text{Maximize} \quad \sum_{d=0}^{D-1} \left( \left( \sum_{S_i \in \mathcal{S}} gs_i^d - pnltsd_i^d \right) + \left( \sum_{T_j \in \mathcal{T}} gt_j^d - pnltsd_j^d \right) \right) \quad (32) $$

### 4.4.5 MILP

Since the model is a Mixed-Integer Linear Programming (MILP), any solver can find an optimal solution. It is possible to study how the marketplace behaves to a certain extent. In addition, it will serve as an optimal solution to compare with heuristic solutions for small instances. However, the solver demands more time to find an optimal solution in larger instances. Besides, using linear programming makes decisions inside each data center (e.g., scheduling inside the DC), which is not the main objective of our work. Therefore, Sect. 5 introduces a heuristic to solve this problem in a reasonable time for any instance size and considering the data centers as black boxes.

## 4.5 Discussion on the model

As mentioned before, our model considers the data centers as black boxes without knowing their status. Therefore, we focus on the job allocation to the data centers. This leads to some simplifications. For example, the model does not consider the data location and movement costs, network latency, and bandwidth limitations. In addition, our task model assumes that the total load is flexible and known in advance, which is not always the case. Another possibility of improvement is related to the price/penalty model. Other costs, such as infrastructure costs, and other QoS penalties, such as latency, can be included in this part of the model. The same applies to the energy consumption (e.g., adding cooling using PUE). In addition, it is possible to imagine a model that includes the price of the power grid to set the price. In this case, it would not use only renewable energies, but could be considered as an intermediate model. While these aspects are interesting, they do not change the auction model. Our model is general enough, allowing
different proposals on the data center side. Therefore, their introduction would not alter the results presented in the following sections.

## 5 Heuristic

The heuristic consists of two parts: the auction and the scheduling algorithms. Both parts define the behavior of a data center in the marketplace. The heuristic respects the same constraints as the model. We consider that the power available $Pre_k^d$ is known in advance for each time slot $k$ inside $\mathcal{H}$. This knowledge allows the heuristic to keep the power consumption below the power available (Constraint (12)). This assumption is fair enough, considering that there are several models with good accuracy to predict weather conditions and power production [31, 32]. On the other hand, the heuristic only discovers the jobs when they arrive, working as an online scheduling. Therefore, the heuristic cannot find an optimal solution without knowing all future jobs. Algorithm 1 presents the main process of the marketplace.

<table><caption>**Algorithm 1** Main process.</caption><thead><tr><th></th><th></th><th></th></tr></thead><tbody><tr><td>1</td><td>begin</td><td></td></tr><tr><td>2</td><td></td><td>totalMoney = [];</td></tr><tr><td>3</td><td></td><td>for d ∈ DC do</td></tr><tr><td>4</td><td></td><td>totalMoney[d] = 0;</td></tr><tr><td>5</td><td></td><td>end</td></tr><tr><td>6</td><td></td><td>for k ∈ [0, K − 1] do</td></tr><tr><td>7</td><td></td><td>W = getWorkload(k);</td></tr><tr><td>8</td><td></td><td>for job in W do</td></tr><tr><td>9</td><td></td><td>dcWinner, price = getBestBid(k, DC, job);</td></tr><tr><td>10</td><td></td><td>if dcWinner == None then</td></tr><tr><td>11</td><td></td><td>continue;</td></tr><tr><td>12</td><td></td><td>penalty = scheduleJob(k, dcWinner, job);</td></tr><tr><td>13</td><td></td><td>totalMoney[dcWinner] +=</td></tr><tr><td>14</td><td></td><td>price − penalty;</td></tr><tr><td>15</td><td></td><td>W.remove job;</td></tr><tr><td>16</td><td></td><td>end</td></tr><tr><td>17</td><td></td><td>end</td></tr></tbody></table>

Lines 2-5 of Algorithm 1 initialize the total money of each data center. Then, the block of lines 6-16 processes each time slot $k$ inside the time window $\mathcal{H}$. Line 7 gets the workload at instant $k$ with the jobs not previously scheduled and the jobs that arrived in the time slot. The function

$get_workload(k)$ sorts the jobs in the queue, putting all tasks before the services with both in descending price order. So, the queue $\mathcal{W}$ has first all tasks, from the highest price to the lowest, and then all services, equally sorted. $\mathcal{W}$ has all the jobs' data, such as prices, penalties, workload demanded, etc. When it is impossible to bid on a job (Constraints (17) and (18)), the function $get_workload(k)$ removes this job from $\mathcal{W}$. Then, lines 8-15 process each job inside the workload $\mathcal{W}$. For each job $job$ inside $\mathcal{W}$, the function $get_best bid(k, DC, job)$ gets the winner data center with the price of the job. Section 5.1 details this function. If there is no winner (line 10), it does not schedule the job, which stays in $\mathcal{W}$. If there is a winner, the heuristic schedules the job in line 12 (function schedule_job(k, dc winner, job)) is detailed in Sect. 5.2). Regarding the complexity, the first for loop (lines 6-16) is the execution over time, which can be ignored. The second loop (lines 8-15) has a complexity of $O(n)$ (n being the number of jobs). The functions $get_best bid$ (the next section presents it) and schedule_job are mainly executed on the data center side and in parallel.

### 5.1 Auction

After describing the main process of the heuristic, this section focuses on the auction process. The main idea is that the data center with the lowest bid value wins the job. The heuristic includes the concept of cooperative and non-cooperative behaviors. In non-cooperative, an aggressive data center drastically reduces its bid value, winning the job, but at a lower price. It is possible to think of this auction in two rounds. In the first round, all cooperatives bid using the market price, and the non-cooperatives bid with a lower bid value (because they accept to reduce the earned money). In a case where all data centers are cooperative, all data centers always bid using the same market price. To select the data center which will benefit the most in this cooperative version, the tie will be broken by finding the data center where this task will incur the lowest penalty. In this case, the auction process can run a second round, asking which data center has the highest gain to run it. The data center with the highest gain takes the job receiving the market price. On the other hand, if at least one data center is aggressive, it reduces its bid and takes the job in the first round. In this case, it receives the price of the second lowest bid. Algorithm 2 presents the auction in a simplified manner, dealing with it on only one round and considering that it knows if it is cooperative or non-cooperative in advance. This algorithm shows how each
data center finds the value to bid (function *bid_job(d, job*) from Algorithm 1).

<table><caption>**Algorithm 2** Algorithm for the auction process (function *get_best_**bid(k, DC, job)).</caption><thead><tr><th></th><th></th><th></th></tr></thead><tbody><tr><td>input :</td><td>Time slot k, data centers DC, and job job.</td><td></td></tr><tr><td>output:</td><td>Data center winner and price</td><td></td></tr><tr><td>begin</td><td></td><td></td></tr><tr><td>1</td><td>bids = [];</td><td></td></tr><tr><td>2</td><td>for d ∈ DC do</td><td></td></tr><tr><td>3</td><td>| bids[d] = None;</td><td></td></tr><tr><td>4</td><td></td><td></td></tr><tr><td>5</td><td>end</td><td></td></tr><tr><td>6</td><td>for d ∈ DC do</td><td></td></tr><tr><td>7</td><td>| penalty = get_lowerPenalty(k, d, job);</td><td></td></tr><tr><td>8</td><td>| price = get_price(k, job);</td><td></td></tr><tr><td>9</td><td>| gain = price - penalty;</td><td></td></tr><tr><td>10</td><td>if gain &lt;= 0 then</td><td></td></tr><tr><td>11</td><td>| continue;</td><td></td></tr><tr><td>12</td><td>if coop then</td><td></td></tr><tr><td>13</td><td>| bids[d] = price - gain;</td><td></td></tr><tr><td>14</td><td>else</td><td></td></tr><tr><td>15</td><td>| bids[d] = price - (gain × d.aggr);</td><td></td></tr><tr><td>16</td><td>end</td><td></td></tr><tr><td>17</td><td>end</td><td></td></tr><tr><td>18</td><td>if len(bids) == 0 then</td><td></td></tr><tr><td>19</td><td>| return None, 0;</td><td></td></tr><tr><td>20</td><td>if len(bids) == 1 or coop then</td><td></td></tr><tr><td>21</td><td>| return get_winners(bids), get_price(k, job);</td><td></td></tr><tr><td>22</td><td>return get_winners(bids), get_second_bid(bids);</td><td></td></tr><tr><td>23</td><td>end</td><td></td></tr></tbody></table>

Before detailing this algorithm, it is important to explain two main concepts of the auction algorithm: the price and bid value. The price is how much the data center receives if it wins the auction process. The bid value is the minimal value that it accepts to receive. The lowest bid value wins the job, but the real price can vary according to the bid from the other data centers. Algorithm 2 starts by initializing an array of bids in lines 2-5. Each index of this variable is the data center index *d*. Then, lines 6-16 process each data center. Line 7 uses the function *get_lowerPenalty(k, d, job)* to find the lowest expected penalty possible in the data center *d* for job *job*. It considers the actual core allocation in this decision. This function is better explained in Sect. 5.2 since it uses the same idea applied to the scheduling process. Then, the heuristic calculates the market price (line 8) using Equation (31) (for tasks) or Equation (30) (for services) at instant *k*. After that, it calculates the expected gain in line 9. At this point, we have the market price at instant *k* (*price*), expected penalty (*penalty*), and expected gain (*gain*) calculated. If the *gain* is lower or equal to zero, the data center does not bid (line 11). If *gain* > 0, we calculate the bid value for this data center. The bid value depends on whether we are in a

cooperative system (*coop* = True and *d.aggr* = 0 for every data center).

If it is cooperative, all data centers agree to bid using the market price minus the gain (line 13), making the data center with the highest gain have the lowest bid value. However, if we are in a non-cooperative system (at least one aggressive), the bid value is given by line 15. *d.aggr* indicates the data center aggressiveness. In this case, the non-aggressive data centers always bid using the job price (since *d.aggr* = 0). For a very aggressive data center (*d.aggr* = 1), the bid value will be the price minus the gain. An aggressiveness of 1 means that the data center accepts jobs even if the total money received will be zero.

So, *bids* has all bids from the data centers at the end of the loop from lines 6-17. Now, the algorithm needs to find the winning data center and the job price. If it does not have any bid (line 18), we do not have a winner, returning None for the data center (line 19). We consider that the function *len(bids)* ignores the values equal to None. If it has only one bid or we are in a cooperative system (line 20), we return the data center with the lowest bid (function *get_winners(bids)*) and the price from the market (Equations (30) and (31)). In cooperative mode, we give the job to the data center with the highest gain (which has the lowest bid), using the price from the market. Also, if we have only one bid (independently of non-cooperative or cooperative), we do not have competition. So, the only bidder receives the job with the market price.

However, if we are in a non-cooperative system with more than one bid, we apply a reverse Vickrey auction system [33, 34]. The winner is the one with the lowest bid but with the price of the second-lowest bid value. The idea behind giving the second-lowest bid value as price is that this data center would win the job for any value lower than the second-lowest. If we have two or more data centers with the same lowest bid, the function *get_winners(bids)* chooses randomly among them, and the function *get_second_bid(bids)* returns the same lowest bid (since the second-lowest is equal to the lowest). In a nutshell, in the cooperative system, all data centers bid using the price

<figure><img src="image_8.png" /><figcaption>**Fig. 3** Aggressiveness impact on the auction process and price. The job market price in this example is fixed to 100. *Aggre* = 0 means the data center is not aggressive, and *Aggre* = 1 means that the data center is aggressive</figcaption></figure>
minus gain, and the winner is the data center with the lowest bid (so the one that can make more money) and receives the price of the job. In the non-cooperative system, the aggressive data centers bid using price minus gain, the cooperatives bid using the price, and the winner (lowest bid) receives the second-lowest bid as the price of the job. Figure 3 exemplifies this behavior.

First, for example, we have a cooperative system with two data centers with the same bid value. So, it chooses randomly among them, receiving the market price (no auction system). However, in the non-cooperative system with one aggressive, the aggressive wins the job, receiving the price of the second-best (reverse Vickrey auction system). This model could encourage the data centers to be aggressive. Nevertheless, in the case of two (or more) aggressive data centers, the winner executes the job without receiving money since the second-best bid is also 0. Back to Algorithm 2, it is important to highlight that even if we present the algorithm as a procedural pseudo-code, this algorithm runs with some parts in parallel. All the data center bid calculation (lines 7-16) is executed inside each data center. The complexity of the data center side depends on the algorithm implemented to estimate the scheduling (function *get_lower,**penalty* discussed in the next section). Lines 1-6 and 17-22 are executed in the central marketplace. Even if lines 1-6 show a *for loop*, it is only an initialization and is done using cache. We let it as a *for loop* to simplify the algorithm. Therefore, the complexity is $O(1)$ on the marketplace side too.

## 5.2 Scheduling

Following the auction process, this section describes the heuristic scheduling algorithm. Unlike the auction process, the scheduling algorithm runs entirely on the data center side. Here, we propose an algorithm to simulate the data center behavior, but this can be any scheduling algorithm from the state of the art. In addition, the complexity of this algorithm varies according to the implementation inside the data center. Our approach does not increase this complexity. The scheduling main idea is present in the functions *get_lower,**penalty*(*k*, *d*, *job*) from Algorithm 2 and *schedule_job*(*k*, *dc_winner*, *job*) from Algorithm 1. *get_lower*_penalty(*k*, *d*, *job*) makes a pre-scheduling, but without placing the job. On the other hand, *schedule_job*(*k*, *dc_winner*, *job*) places the job. The key idea behind the scheduling is to find which core can return the best QoS to the data center. Since we are in a environment exclusively linked to renewable energies, the scheduling must respect Constraint (12). In addition, since tasks and services have different QoS and behaviors, the scheduling deals with

them differently. Algorithm 3 presents the algorithm implemented inside *get_lower*_penalty(*k*, *d*, *job*) and *schedule_job*(*k*, *dc_winner*, *job*).

<caption>**Algorithm 3** Algorithm for the scheduling.</caption>

input : Time slot k, data center d, and job job.
output: Lowest penalty
1 begin
2 & penalties = [];
3 & for c ∈ C^d do
4 & & penalties[c] = 0;
5 & end
6 & for c ∈ C^d do
7 & & if job ∈ T then
8 & & & // It is a task
9 & & & & j = job.index; load = wtj; k' = k;
10 & & & & while load > 0 and k' < K do
11 & & & & & load -=
12 & & & & & & max_load_increment(k', d, c);
13 & & & & & k' += 1;
14 & & end
15 & & penalties[c] = task_penalty job, k';
16 else
17 & & & // It is a service
18 & & & & i = job.index;
19 & & & & for k' ∈ [[ss_i, fs_i - 1]] do
20 & & & & & max_load =
21 & & & & & & max_load_increment(k', d, c);
22 & & & & & & done = min( ws_{i,k'}, max_load );
23 & & & & & & penalties[c] +=
24 & & & & & & serv_penalty job, ws_{i,k'},
25 & & & & & & done );
26 & & end
27 & end
28 & end
29 & lowest_penalty, core =
30 & & get_lowest_penalty penalties );
31 & return lowest_penalty;
32 end
33 end
end

First, the algorithm initializes the penalty array in lines 2-5. Then, it processes each core *c* of the data center *d* in lines 6-22. Line 7 separates the penalty evaluation of tasks (lines 8-13) and services (lines 15-20). Considering the tasks, line 8 gets the job index and the total load to execute (variable *load*). This line also initializes *k'* with the current time slot *k*. After that, it iterates over time slots *k'* until the end of the time window or *load* = 0 (line 9). So, for each *k'*, the algorithm verifies how much load is available by using the function *max_load_increment*(*k'*, *d*, *c*). This function finds how much it can increase $\alpha_{j,k}^{d,c}$, maintaining the power consumption lesser or equal to $Pre_k^d$ (Constraint (12)) and $(\sum_{S_j \in S} \alpha_{i,k}^{d,c} + \sum_{T_j \in T} \alpha_{j,k}^{d,c}) \le 1$ (Constraint (13)). It is important to highlight that this function
does not reduce the load of the previous scheduling. Then, it increments $k'$. At the end of the loop from lines 9-12, $k'$ has the finish time. Using it, we can calculate the penalty using Equation (26).

Regarding the services, line 15 takes the service index. Then, it iterates over time slots $k'$ from $ss_i$ to $fs_i - 1$, which represents the service duration. At each time slot $k'$, line 17 gets how much load is available, using the same function `max_load_increment()` (k', d, c) from line 10. Then, the algorithm defines the workload done by this service in this core as the lowest value between the load demanded and the maximum possible. Then, line 19 calculates the penalty. If ($ws_{i,k'} \le \max_load$), the function `serv_penalty()` returns 0 ($ws_{i,k'} = \text{done}$). If not, it returns the penalty using Equation (27). After calculating the penalties, line 23 uses the function `get_lowest_penalty()` to get the lowest penalty and core. If there is more than one with the same lowest penalty, it takes the core with the highest usage. If there is more than one with the same lowest penalty and highest usage, it chooses randomly among them. Finally, it returns the penalty `lowest_penalty` on line 24. The only difference between `get_lower_penalty(k, d, job)` and `schedule_job(k, dc_winser, job)` is that `schedule_job(k, dc_winser, job)` places the job in the core `core`, updating the core usage before returning the lowest penalty.

# 6 Experimental environment

After describing the model and heuristic in previous sections, this section describes the experimental environment and the results. We provide a GitLab with all implementation and experiments source code.<fnref n="1" /> We executed the experiments on Grid5000 Montcalm-1 machine.<fnref n="2" /> This machine contains 2 Intel Xeon Silver 4314 CPUs (16 cores each), 256 GiB of memory, an SSD of 960 GB, and a network of 10 Gbps. Fixing one single machine to run our experiments allows other researchers to reproduce our experiments with similar results. In addition, we provide the framework installation using NixOS,<fnref n="3" /> which allows anyone to install the same packages and versions used in our experiments. The GitLab has a *read-me* file with a tutorial to execute the experiments.

We implemented both the linear programming and the heuristic using Python programming language. Regarding the linear programming implementation, we created a model using PuLP.<fnref n="4" /> This framework provides an interface,

allowing the creation of a unique model that can be solved using different solvers, such as COIN-OR, CPLEX, GUROBI, etc. In our experiments, we solved the model using GUROBI. The heuristic is quite straightforward, demanding only the NumPy library. In all following experiments, we simulated a three-day time window $H$. We defined $\Delta t$ as equal to 1 h, resulting in 72 time slots ($K = 72$).

Our experimental campaign consists of three phases. First, we compare our heuristic to the MILP solutions (Sect. 7.1). The objective is to verify the gap between MILP and the heuristic solutions. The MILP can not be applied in practice because it takes too long to solve medium/large instances and makes decisions on the data center side (e.g., scheduling the jobs). However, the MILP is crucial as a base for comparison. The second experiment is to compare a centralized approach with a distributed one (Sect. 7.2). The objective is to evaluate if the distributed approach is better than a centralized one in our auction process model. In addition, our auction process would be useless if the distributed architecture were worse than a centralized one. Finally, the last experiment compares cooperative and non-cooperative approaches under our auction process (Sect. 7.3). We evaluate them using three renewable energy productions to avoid bias from the energy production. The first renewable energy production is equal for every data center. This allows us to compare the behavior of each data center individually, showing the impact of the non-cooperative on the cooperatives. Using two synthetic (one with the same power production for all data centers and another with time variation) and a real power trace, we do a global analysis of the non-cooperative effects, highlighting the improvements of the cooperative approach.

The following sections describe other aspects of our experimental environment, such as the simulated data centers, renewable energy production, and workload. After that, we present the experimental campaigns and the obtained results in Sect. 7.

## 6.1 Simulated data centers

We simulated and compared two data center configurations: centralized and distributed. Figure 4 illustrates these configurations. In both configurations, we have a centralized marketplace that receives the requests from the user. The distributed configuration has each data center in a different location. Therefore, each data center can have different power production. Nevertheless, they are homogeneous, having the same IT and power infrastructure. So, the only difference comes from the weather conditions.

<footnote n="1">¹ https://gitlab.irit.fr/sepia/scheduling/distributed/market-place</footnote>

<footnote n="2">² https://www.grid5000.fr in Toulouse.</footnote>

<footnote n="3">³ https://nixos.org/</footnote>

<footnote n="4">⁴ https://coin-or.github.io/pulp/</footnote>
<figure><img src="image_9.png" /><figcaption>Fig. 4 Comparison between centralized and distributed approaches. The centralized and distributed configurations have the same total number of servers, solar panels and wind turbines</figcaption></figure>

In the centralized configuration, both IT and power infrastructures have the same capacity as the sum of all distributed data centers. We defined that each distributed data center has 4 cores, so the centralized one has 16 cores. In our experiments, all cores are homogeneous with $Pstat^{d,c} = 20$ and $Pdyn^{d,c} = 140$. We applied the same capacity rule to wind turbines and solar panels. Thus, the centralized can produce four times more energy than each distributed data center. However, since it is centralized, it is submitted to just one weather.

## 6.2 Renewable energy production

Concerning renewable energy production, we created three patterns of power production: *Equal*, *Variable*, and *Real*. Figure 5 illustrates the three patterns. Even with different patterns, the total energy is 55296 Wh within three days. This energy corresponds to 30 % of the total energy used to keep all data centers at maximum load for three days. *Equal* pattern produces the same power on each data center at each time slot. This pattern follows a bell curve. *Variable* pattern creates four different curves for each data center. Data center 0 produces the same curve as the *Equal* pattern. Data centers 1 and 2 have a bell curve with offset and amplitude variations from the previous one, and data center 3 has constant power production. Both *Equal* and *Variable* split equally the total energy among the four data centers (13824 Wh for each data center). Finally, we generated the *Real* pattern, taking weather conditions traces from the Renewable Ninja tool [35]. This tool uses data from NASA [36], and been used in several papers, such as [37–39], to cite a few. We defined different locations for each data center and its energy production as follows:

* DC 0: Canberra (15633.89 Wh);

* DC 1: Dubai (10589.74 Wh);

* DC 2: Paris (13020.46 Wh);

* DC 3: São Paulo (16051.91 Wh).

The sum of the energy is equal to the other patterns (55296 Wh) but with some data centers having higher production than others. In the centralized data center configuration, the power production follows the same patterns but with the values normalized to have the same amount of energy as the sum of the distributed ones (55296 Wh). Section 7 explains how we combine the power productions with the data center configurations.

## 6.3 Workload

Regarding the workload, all the experiments in Sect. 7 use the same methodology. We create a synthetic workload based on the generator proposed in [40]. This workload generator has been used in several papers, such as [41–43], to cite a few. The authors created this generator based on a statistical analysis of Google Trace. This workload is composed of services and jobs. Then, we create three workload sizes, as follows:

* *Small*: 80 services and 80 tasks;

* *Medium*: 159 services and 159 tasks;

* *Large*: 238 services and 238 tasks;

For each size, we create 100 different workloads. So, we have 100 workloads with small size, 100 with medium size, and 100 with large size. We chose the number of services and jobs considering the load generated in the data center. The average load of the 100 small workloads is around 10 % of the cores' full capacity (ignoring power constraints, that is, all the cores at 100 % during all time slots), the medium is 20 %, and the large is 30 %. Since we are in an environment only linked to renewable energies, we do not have full capacity. As presented in Sect. 6.2, we generate energy to run only 30 % of the data center capacity. Therefore, the large workloads demand maximum possible usage under the power constraints, while medium and small workloads have reduced demand. The results in Sect. 7 consider the average of the 100 workloads for each size.

# 7 Experiments and results

Using the experimental environment presented in the previous section, we create three experiments to analyze the different aspects of the marketplace. First, we present in Sect. 7.1 a comparison between MILP and Heuristic results. This comparison shows the gap between the heuristic solution and the optimal result. In addition, it compares the solution time of both propositions. Then, Sect. 7.2 compares centralized and distributed
<figure><img src="image_10.png" /><figcaption>**Fig. 5** Renewable energy production patterns (from wind and sun) used to simulate the power production on each data center. *Equal* follows a bell curve, *Variable* creates different patterns based on bell curves, and *Real* uses real traces from NASA using Renewable Ninja tool</figcaption></figure>

configurations. This experiment highlights the importance of the distributed configuration in this renewable-only marketplace. After that, Sect. 7.3 discusses the impact of the non-cooperative marketplace. Sects. 7.2 and 7.3 present the average results of all executions. We present only averages to simplify the visualization. The standard deviation of all metrics is below 5 % in most cases. To make our experiments reproducible, we provide all the code and experiments <fnref n="5" />,<fnref n="6" /> Finally, Sect. 7.4 presents a global analysis of all results. The following sections present the combination of the data center configuration (from Sect. 6.1) and renewable energy production (from Sect. 6.2) for each experiment. Each combination runs all workloads from Sect. 6.3.

## 7.1 MILP and Heuristic comparison

In this section, we compare the MILP and heuristic solutions. MILP can find the optimal solution for the problem but with a longer solution time. The idea is to verify how far the heuristic solution is from the optimal. Since MILP takes several minutes to solve the problem, we selected only one configuration and renewable energy production. The selected configuration is the distributed one, with the *Equal* renewable energy production. Aiming to reduce the solution time, we also defined an acceptable gap of 5 % from the theoretical optimal. Using GUROBI, we solved all large, medium, and small workloads. First, Table 2

presents the solution time for the different workload sizes and algorithms.

Even with the allowed gap in the solver, the MILP executions take a very long time to find a solution, mainly in the large workload. The MILP worst case takes more than 30 min to find a solution. The average time in the large workload is 4 min and 55 s. Medium and small workloads have shorter execution times, but they are still far from the times of the heuristic. The heuristic execution time is always below 300 ms. Regarding the money obtained, Table 3 shows the gap in the result obtained by the heuristic compared to the MILP. So, for example, if the MILP result is 100 and the heuristic result is 40, the gap is 60 %. The table shows that in the majority of the cases, the heuristic earns more than half of the optimal possible benefit. A big difference between the heuristic and MILP is that the heuristic only knows the jobs when they arrive, while the MILP has complete knowledge of all jobs. Therefore, this result seems good enough.

## 7.2 Centralized and distributed comparison

Now, we compare the centralized and distributed configurations. The idea is to verify if a distributed configuration can increase the money received and QoS compared to the centralized one. We created the following combinations of configuration (from Sect. 6.1) and renewable energy production (from Sect. 6.2):

*   **Cen. Equal**: The centralized configuration with the *Equal* power production pattern;

*   **Cen. Config**: The centralized configuration with the *Real* power production of each data center. We have four possible configurations (using every *Real* power production): *Cen. Conf. 0*, *Cen. Conf. 1*, *Cen. Conf. 2*, *Cen. Conf. 3*;

*   **Distr. Equal**: The distributed configuration with *Equal* renewable energy production for each data center;

*   **Distr. Real**: The distributed configuration with *Real* renewable energy production for each data center;

As mentioned in Sect. 6.2, all executions have the same total renewable energy, allowing us to compare centralized and distributed executions. Table 4 presents the average for each combination, considering the three different workloads (large, medium, and small). The table presents the global results, ignoring the results by each data center in the distributed configurations. We divided the results into three metric groups: Bid, QoS, and Money/Energy. The bid group shows the percentage of tasks and services taken by the data centers. The QoS metric group presents three metrics. The % service metric indicates how much workload from the taken services is finished. The second metric (*Before due*) indicates the percentage of the tasks that are

<footnote n="5">⁵ https://gitlab.irit.fr/sepia-pub/open-science/cooperative-vs-non-cooperative-marketplace/</footnote>

<footnote n="6">⁶ https://doi.org/10.5281/zenodo.15166838</footnote>
<table><caption>**Table 2** Solution time (in seconds) of the MILP and heuristic over the 100 workloads for each workload size</caption><thead><tr><th>Size</th><th>Algo.</th><th>Avg.</th><th>std</th><th>Min</th><th>Max</th></tr></thead><tbody><tr><td rowspan="2">Large</td><td>MILP</td><td>295.15</td><td>209.85</td><td>141.71</td><td>1883.51</td></tr><tr><td>Heuri</td><td>0.19</td><td>0.01</td><td>0.17</td><td>0.23</td></tr><tr><td rowspan="2">Medium</td><td>MILP</td><td>111.34</td><td>25.86</td><td>71.44</td><td>202.03</td></tr><tr><td>Heuri</td><td>0.12</td><td>0.01</td><td>0.10</td><td>0.14</td></tr><tr><td rowspan="2">Small</td><td>MILP</td><td>36.35</td><td>5.82</td><td>28.71</td><td>61.69</td></tr><tr><td>Heuri</td><td>0.06</td><td>0.01</td><td>0.05</td><td>0.08</td></tr></tbody></table>

<table><caption>**Table 3** Gap (in %) between the result of the heuristic and the MILP</caption><thead><tr><th>Size</th><th>Avg.</th><th>Std</th><th>Min</th><th>Max</th></tr></thead><tbody><tr><td>Large</td><td>46.79</td><td>1.61</td><td>42.31</td><td>50.27</td></tr><tr><td>Medium</td><td>45.11</td><td>1.52</td><td>42.25</td><td>48.47</td></tr><tr><td>Small</td><td>43.35</td><td>1.90</td><td>38.58</td><td>47.60</td></tr></tbody></table>

finished before the due date (considering only the bid tasks). The tasks not included in this percentage ended between the due date and the deadline. We do not have tasks finished after the deadline because the expected gain is negative, and the heuristic does not take these tasks. The third metric is the tasks' slowdown, which indicates the waiting time relative to the task size. The slowdown is given by slowdown = $\frac{waiting+execution}{execution}$, where waiting is the waiting time and execution is the execution time. The minimal slowdown possible is 1, and the lower the better. Finally, the last metric group is Money/Energy, which has three metrics also. First, the benefit shows how much money the data centers earned in the experiment. The second metric is the percentage of wasted energy, that is, the renewable energy available that is not used. Finally, we present a metric named Ratio, given by the benefits divided by the energy available. A high Ratio indicates that we can transform the energy available into money. A high benefit and low wasted energy result in a high ratio.

<table><caption>**Table 4** Average results for large, medium, and small workloads in centralized and distributed configurations. The bolditalic values indicate the best result for each column and workload size</caption><thead><tr><th rowspan="2"></th><th colspan="2">Bid</th><th colspan="3">QoS</th><th colspan="3">Money/Energy</th></tr><tr><th>Tasks (%)</th><th>Services (%)</th><th>Service (%)</th><th>Before due (%)</th><th>Slowdown</th><th>Benefits (×1000)</th><th>Energy wasted (%)</th><th>Ratio</th></tr></thead><tbody><tr><td colspan="9"><strong>Large</strong></td></tr><tr><td>CentralEQUAL</td><td>71.96</td><td>65.09</td><td>95.29</td><td>96.65</td><td>1.44</td><td>95.86</td><td>31.65</td><td>1.73</td></tr><tr><td>CentralReal DC 0</td><td>69.88</td><td>56.20</td><td>93.53</td><td>95.17</td><td>1.70</td><td>87.33</td><td>37.60</td><td>1.58</td></tr><tr><td>CentralReal DC 1</td><td>57.84</td><td>49.34</td><td>91.69</td><td>94.85</td><td>1.56</td><td>73.19</td><td>47.56</td><td>1.32</td></tr><tr><td>CentralReal DC 2</td><td>76.55</td><td>66.28</td><td><strong>95.45</strong></td><td>97.33</td><td>1.54</td><td>100.54</td><td>27.20</td><td>1.82</td></tr><tr><td>CentralReal DC 3</td><td>63.85</td><td>53.65</td><td>92.95</td><td>94.59</td><td>1.66</td><td>80.72</td><td>41.05</td><td>1.46</td></tr><tr><td>DistribEQUAL</td><td>71.84</td><td>72.02</td><td>88.30</td><td>97.17</td><td><strong>1.34</strong></td><td>96.79</td><td>32.73</td><td>1.75</td></tr><tr><td>DistribReal</td><td><strong>87.87</strong></td><td><strong>83.98</strong></td><td>90.97</td><td><strong>98.57</strong></td><td>1.49</td><td><strong>118.81</strong></td><td><strong>15.31</strong></td><td><strong>2.15</strong></td></tr><tr><td colspan="9"><strong>Medium</strong></td></tr><tr><td>CentralEQUAL</td><td>77.45</td><td>72.38</td><td>95.43</td><td>97.02</td><td>1.32</td><td>70.02</td><td>50.23</td><td>1.27</td></tr><tr><td>CentralReal DC 0</td><td>78.77</td><td>68.26</td><td>94.40</td><td>96.58</td><td>1.49</td><td>68.45</td><td>51.15</td><td>1.24</td></tr><tr><td>CentralReal DC 1</td><td>62.65</td><td>55.41</td><td>90.99</td><td>95.88</td><td>1.46</td><td>53.65</td><td>61.70</td><td>0.97</td></tr><tr><td>CentralReal DC 2</td><td>83.77</td><td>76.18</td><td><strong>96.37</strong></td><td>98.33</td><td>1.33</td><td>75.31</td><td>45.26</td><td>1.36</td></tr><tr><td>CentralReal DC 3</td><td>71.97</td><td>62.67</td><td>93.76</td><td>95.63</td><td>1.51</td><td>62.07</td><td>54.93</td><td>1.12</td></tr><tr><td>DistribEQUAL</td><td>75.72</td><td>76.41</td><td>89.61</td><td>97.34</td><td><strong>1.21</strong></td><td>68.79</td><td>51.82</td><td>1.24</td></tr><tr><td>DistribReal</td><td><strong>94.86</strong></td><td><strong>94.04</strong></td><td>95.91</td><td><strong>99.38</strong></td><td>1.27</td><td><strong>88.94</strong></td><td><strong>34.63</strong></td><td><strong>1.61</strong></td></tr><tr><td colspan="9"><strong>Small</strong></td></tr><tr><td>CentralEQUAL</td><td>84.84</td><td>79.09</td><td>95.86</td><td>98.23</td><td>1.21</td><td>38.28</td><td>72.41</td><td>0.69</td></tr><tr><td>CentralReal DC 0</td><td>88.70</td><td>80.36</td><td>95.56</td><td>98.34</td><td>1.28</td><td>39.62</td><td>71.17</td><td>0.72</td></tr><tr><td>CentralReal DC 1</td><td>70.81</td><td>64.64</td><td>90.99</td><td>97.36</td><td>1.30</td><td>30.98</td><td>77.69</td><td>0.56</td></tr><tr><td>CentralReal DC 2</td><td>89.24</td><td>85.59</td><td>97.27</td><td>98.72</td><td>1.17</td><td>41.38</td><td>69.54</td><td>0.75</td></tr><tr><td>CentralReal DC 3</td><td>81.94</td><td>75.59</td><td>94.53</td><td>97.24</td><td>1.30</td><td>36.58</td><td>73.01</td><td>0.66</td></tr><tr><td>DistribEQUAL</td><td>78.53</td><td>79.56</td><td>89.77</td><td>97.40</td><td>1.13</td><td>35.76</td><td>74.21</td><td>0.65</td></tr><tr><td>DistribReal</td><td><strong>98.46</strong></td><td><strong>98.50</strong></td><td><strong>98.91</strong></td><td><strong>99.89</strong></td><td><strong>1.12</strong></td><td><strong>47.02</strong></td><td><strong>64.20</strong></td><td><strong>0.85</strong></td></tr></tbody></table>
Regarding the results from Table 4, it is possible to notice that *Distr. Real* has the best availability with the highest number of tasks and services taken for all workloads. This availability is possible since we spread our data centers in several locations, having different power productions. Due to this high availability, the *Distr. Real* configuration has the highest earned money and lowest wasted energy, resulting in the best benefits/energy available ratio. However, we can see a % service degradation on the large workload for this configuration, finishing 90.97 % of the service workload (while the best centralized finished 95.45 %). Two reasons explain this degradation. First, our heuristic prioritizes the tasks before services. We can see that this configuration has the best percentage of finished tasks before the due date. Second, *Distr. Real* takes a lot more jobs than the other executions, overcharging the data centers. So, it is necessary to degrade the services to find a place for them. Nevertheless, we can see that in the medium workload, *Distr. Real* approximates the % service metric to the best one, and it has the best one in the small workload. Finally, we do not see a big impact on the slowdown of *Distr. Real* configuration compared to the other configurations.

The *Distr. Equal* configuration cannot provide the same high availability since it has the same power production patterns for every data center. This result highlights the importance of spreading the data centers in locations with different weather productions. Among the centralized configurations, we can see that *Cen. Config.* 2 has better results compared to the other ones. Its power production has a flatter pattern, keeping cores available for more time. So, it can bid for more jobs (which increases the benefits and reduces the wasted energy). This pattern also helps to have a good QoS. Regarding the task slowdown of the centralized with *Real* power production, these configurations can make the tasks wait longer to start since they can have longer periods with lower power production. This behavior is mainly noticeable in large workloads. In small and medium workloads, there is space available to place the jobs as soon as they arrive (or with a small waiting time).

## 7.3 Non-cooperative and cooperative comparison

After the centralized and distributed comparison, this section focuses on non-cooperative and cooperative systems. The idea is to verify the impact of aggressiveness in a marketplace environment. All non-cooperative and cooperative experiments are done using the distributed configuration (there is no competition in the centralized ones). With this objective, we propose three experiments. First, Sect. 7.3.1 presents an analysis using the *Equal* power

production. In this analysis, we detail the results of each data center. So, we can verify, for example, the impact of one aggressive data center on the non-aggressive ones. After that, Sect. 7.3.2 considers different renewable energy production, allowing an evaluation of the aggressivity under different power production patterns. Finally, Sect. 7.3.3 discusses the impact of the *Real* power production in non-cooperative and cooperative environments. While Sect. 7.3.1 examines the results by data center, both Sects. 7.3.2 and 7.3.3 provide global analysis. However, our results indicate the same tendencies by each data center in every power production.

### 7.3.1 Equal renewable energy production

Table 5 presents the results for the *Equal* renewable energy production for the medium workloads. Here, all data centers receive the same power production. Due to size constraints, we discuss here only the medium workload. However, large and small workloads present the same tendencies. The table separates the results by data center. We have five configurations:

* *Coop*: Cooperative system;

* 25 %: Non-cooperative system where data center 0 is aggressive. Data centers 1, 2, and 3 are non-aggressive;

* 50 %: Non-cooperative system where data centers 0 and 1 are aggressive. Data centers 2 and 3 are non-aggressive;

* 75 %: Non-cooperative system where data centers 0, 1, and 2 are aggressive. Data center 3 is non-aggressive;

* 100 %: Non-cooperative system where all data centers are aggressive.

The table highlights that the tasks and services are distributed equally among the data centers in the *cooperative*. Regarding the QoS, since the workload is well-balanced among the data centers, no data center is overcharged. So, all data centers have a high % completed service, high jobs finished before the due date, and low slowdown. All data centers have a similar benefit and wasted energy, having a similar Ratio also. This approach is well-balanced providing a fair share of workload for the data centers.

In the non-cooperative 25 % configuration, data center 0 (the aggressive) takes a lot more jobs than the non-aggressive ones. Data center 0 takes jobs even if it does not earn as much as the other data centers. All QoS metrics on all data centers of this configuration are lower than in the *cooperative*. The explanation of data center 0 degradation is related to its load. This data center will take every possible job, even if it cannot provide high QoS. The non-aggressive data centers can only take jobs when the aggressive is fully charged, occurring mainly during low power production moments. However, all data centers
<table><caption>**Table 5** Average results for medium workloads in non-cooperative and cooperative systems using *Equal* renewable production. The bolditalic values indicate the best result for each column</caption><thead><tr><th rowspan="2"></th><th rowspan="2"></th><th colspan="2">Bid</th><th colspan="3">QoS</th><th colspan="3">Money/Energy</th></tr><tr><th>Tasks (%)</th><th>Services (%)</th><th>Service (%)</th><th>Before due (%)</th><th>Slowdown</th><th>Benefits (×1000)</th><th>Energy wasted (%)</th><th>Ratio</th></tr></thead><tbody><tr><td rowspan="4">Coop</td><td>0</td><td>18.45</td><td>19.43</td><td>89.30</td><td>96.91</td><td>1.21</td><td>17.04</td><td>51.68</td><td>1.23</td></tr><tr><td>1</td><td>19.19</td><td>18.40</td><td>90.11</td><td>97.07</td><td>1.20</td><td>17.01</td><td>52.60</td><td>1.23</td></tr><tr><td>2</td><td>19.06</td><td>18.89</td><td>89.70</td><td><strong>97.76</strong></td><td><strong>1.20</strong></td><td>17.17</td><td>51.33</td><td>1.24</td></tr><tr><td>3</td><td>19.02</td><td>19.69</td><td>89.33</td><td>97.50</td><td>1.22</td><td>17.57</td><td>51.65</td><td>1.27</td></tr><tr><td rowspan="4">25% aggre</td><td>0</td><td><strong>44.93</strong></td><td><strong>32.28</strong></td><td>87.06</td><td>94.52</td><td>1.80</td><td><strong>34.91</strong></td><td><strong>4.98</strong></td><td><strong>2.53</strong></td></tr><tr><td>1</td><td>9.88</td><td>15.04</td><td>85.62</td><td>96.23</td><td>1.23</td><td>10.31</td><td>69.38</td><td>0.75</td></tr><tr><td>2</td><td>10.25</td><td>14.96</td><td>86.42</td><td>95.48</td><td>1.22</td><td>10.41</td><td>68.04</td><td>0.75</td></tr><tr><td>3</td><td>10.88</td><td>14.79</td><td>85.83</td><td>96.17</td><td>1.23</td><td>10.63</td><td>68.32</td><td>0.77</td></tr><tr><td rowspan="4">50% aggre</td><td>0</td><td>32.33</td><td>30.43</td><td>90.31</td><td>96.78</td><td>1.42</td><td>6.65</td><td>22.49</td><td>0.48</td></tr><tr><td>1</td><td>32.89</td><td>30.07</td><td>89.69</td><td>97.28</td><td>1.42</td><td>6.66</td><td>22.02</td><td>0.48</td></tr><tr><td>2</td><td>5.25</td><td>8.26</td><td>77.59</td><td>93.91</td><td>1.28</td><td>5.00</td><td>82.96</td><td>0.36</td></tr><tr><td>3</td><td>5.45</td><td>8.40</td><td>79.95</td><td>94.76</td><td>1.24</td><td>5.22</td><td>82.33</td><td>0.38</td></tr><tr><td rowspan="4">75% aggre</td><td>0</td><td>24.18</td><td>23.83</td><td>90.00</td><td>97.12</td><td>1.27</td><td>2.22</td><td>39.49</td><td>0.16</td></tr><tr><td>1</td><td>24.36</td><td>23.87</td><td>90.22</td><td>97.30</td><td>1.28</td><td>1.93</td><td>41.01</td><td>0.14</td></tr><tr><td>2</td><td>23.84</td><td>23.35</td><td><strong>90.59</strong></td><td>97.55</td><td>1.27</td><td>1.88</td><td>39.28</td><td>0.14</td></tr><tr><td>3</td><td>3.58</td><td>5.69</td><td>72.24</td><td>92.87</td><td>1.28</td><td>3.19</td><td>88.26</td><td>0.23</td></tr><tr><td rowspan="4">all aggre</td><td>0</td><td>18.45</td><td>19.43</td><td>89.30</td><td>96.91</td><td>1.21</td><td>0.87</td><td>51.68</td><td>0.06</td></tr><tr><td>1</td><td>19.19</td><td>18.40</td><td>90.11</td><td>97.07</td><td>1.20</td><td>0.88</td><td>52.60</td><td>0.06</td></tr><tr><td>2</td><td>19.06</td><td>18.89</td><td>89.70</td><td><strong>97.76</strong></td><td><strong>1.20</strong></td><td>0.89</td><td>51.33</td><td>0.06</td></tr><tr><td>3</td><td>19.02</td><td>19.69</td><td>89.33</td><td>97.50</td><td>1.22</td><td>0.97</td><td>51.65</td><td>0.07</td></tr></tbody></table>

share these low power production moments in the *Equal* power production. Therefore, the moments where the non-aggressive can take some jobs are the ones with low production. So, they cannot provide high QoS to these jobs. Considering the money/energy, the aggressive data center earns more money and has low wasted energy. Nevertheless, the aggressive makes the other data centers receive less money and waste more energy. Comparing globally the cooperative configuration with the non-cooperative 25% aggressive, we take almost the same number of jobs (around 75% of the services and 76% of tasks), with worse QoS, slightly lower earned money (68790 in cooperative against 66260), and higher wasted energy (51.82% in cooperative against 52.68%).

In the non-cooperative with 50% aggressive configuration, we can see the impact on the metrics of having two aggressive data centers. Both aggressive data centers take a large share of jobs. We still have almost the same global amount number of jobs taken as in the cooperative. Now, with two aggressive data centers, the load is spread among them, reducing the impact on % service and Before due. However, they make the tasks wait longer to start (similar to the 25% aggressive configuration). Considering the benefits, we can see that our model penalizes both

aggressive data centers. In the non-cooperative with 25% aggressive configuration, the aggressive data center earned 34910, but now it earned around 6650, making the money/energy ratio drop to below 1. Finally, the wasted energy of the aggressive increased from 4.98% in the non-cooperative 25% to around 22% in the non-cooperative 50%. The results of 50% aggressive are similar to the 75% aggressive configuration. In 75%, the aggressive ones have the largest share of jobs with good QoS. The main difference is in the benefits. In this configuration, the non-aggressive receives more benefits than the aggressive ones, resulting in a higher ratio, even if the non-aggressive has 88.26% of wasted energy. Finally, the configuration with all aggressive (100%) data centers has a similar bidding policy to the cooperative. Therefore, we have the same bid jobs and QoS in both configurations. The main difference is the earned money due to our price model. This all-aggressive configuration has low benefits compared to the other configurations.

Therefore, it is only interesting to be aggressive if it is the only one aggressive. These results reinforce the need for a cooperative system. The goodness of being aggressive depends highly on the behavior of the other data centers in the marketplace. The following sections continue to
analyze the non-cooperative behavior, varying the power productions. They analyze the metrics globally without detailing the impact of each data center. However, the results of each data center follow the same patterns as this section.

## 7.3.2 Variable renewable energy production

Table 6 shows the results of medium workloads in *Variable* renewable energy production. In this section, each data center has a different power production but still the same total energy. So, it is necessary to create distinct combinations of aggressiveness for the non-cooperative systems. For example, aiming to simulate a non-cooperative configuration with 25 % aggressive data centers, we created four configurations: (i) data center 0 aggressive and the others non-aggressive; (ii) data center 1 aggressive and the others non-aggressive; (iii) data center 2 aggressive and the others non-aggressive; (iv) data center 3 aggressive and the others non-aggressive. Table 6 indicates which data center is aggressive (1) and which data center is non-aggressive (0). For example, the configuration 50 % (0101) means that data center 0 is non-aggressive, data center 1 is aggressive, data center 2 is non-aggressive, and data center 3 is aggressive.

In this experiment, all configurations have quite a similar number of bid jobs, bidding around 96 % of tasks and 95 % of services. Also, all configurations have a similar

wasted energy, from 32.50 % to 34.01 %. Regarding the QoS, Table 6 shows that the cooperative and 100 % (1111) configurations have the best results. As presented in Sect. 7.3.1, these configurations apply the same scheduling policy, which results in the same QoS. However, the cooperative earns a lot more money than the 100 % (1111) configuration. The non-cooperative with 25 % aggressive configurations are among the worst QoS results. For example, while cooperative finishes, on average, 96.90 % of its services, the best non-cooperative 25 % configuration finishes 93.33 %. Concerning the benefits and ratio, the non-cooperative 25 % configurations have the second-best results. It is possible to notice that the QoS goes from the worst results in the 25 % to the best ones in the cooperative and non-cooperative 100 % configurations. On the other hand, the benefit goes from the best in the cooperative to the worst in the non-cooperative 100 %. Additionally, the cooperative configuration makes the marketplace globally more efficient, having the highest global ratio of money/energy. Again, we can see that the cooperative system provides the best all-around configuration.

## 7.3.3 Real renewable energy production

After presenting the *Variable* renewable energy production, this section details the experiments with *Real* renewable energy productions. Differently from previously, this experiment has different total energy on each

<table><caption>**Table 6** Average results for medium workloads in non-cooperative and cooperative systems using *Variable* renewable production. The bolditalic values indicate the best result for each column. The 0/1 notation shows which data center is aggressive (1) and cooperative (0)</caption><thead><tr><th rowspan="2"></th><th colspan="2">Bid</th><th colspan="3">QoS</th><th colspan="3">Money/Energy</th></tr><tr><th>Tasks (%)</th><th>Services (%)</th><th>Service (%)</th><th>Before due (%)</th><th>Slowdown</th><th>Benefits (×1000)</th><th>Energy wasted (%)</th><th>Ratio</th></tr></thead><tbody><tr><td>Cooperative</td><td>96.24</td><td>95.48</td><td><strong>96.90</strong></td><td><strong>99.59</strong></td><td><strong>1.24</strong></td><td><strong>90.77</strong></td><td><strong>32.50</strong></td><td><strong>1.64</strong></td></tr><tr><td>25% (1000)</td><td>96.34</td><td>95.68</td><td>93.33</td><td>97.04</td><td>1.50</td><td>86.15</td><td>33.70</td><td>1.56</td></tr><tr><td>25% (0100)</td><td>96.25</td><td>95.62</td><td>92.77</td><td>95.78</td><td>1.57</td><td>85.48</td><td>34.03</td><td>1.55</td></tr><tr><td>25% (0010)</td><td>96.32</td><td>95.65</td><td>92.53</td><td>95.99</td><td>1.59</td><td>85.13</td><td>34.01</td><td>1.54</td></tr><tr><td>25% (0001)</td><td>96.26</td><td>95.59</td><td>92.58</td><td>96.13</td><td>1.56</td><td>85.19</td><td>33.53</td><td>1.54</td></tr><tr><td>50% (1100)</td><td>96.17</td><td>95.67</td><td>93.40</td><td>97.62</td><td>1.50</td><td>54.31</td><td>33.87</td><td>0.98</td></tr><tr><td>50% (1010)</td><td>96.36</td><td>95.79</td><td>93.47</td><td>98.04</td><td>1.50</td><td>54.27</td><td>33.80</td><td>0.98</td></tr><tr><td>50% (1001)</td><td>96.30</td><td><strong>95.80</strong></td><td>93.45</td><td>97.74</td><td>1.46</td><td>53.18</td><td>33.32</td><td>0.96</td></tr><tr><td>50% (0110)</td><td>96.30</td><td>95.48</td><td>93.34</td><td>97.85</td><td>1.52</td><td>49.18</td><td>33.98</td><td>0.89</td></tr><tr><td>50% (0101)</td><td>96.14</td><td>95.50</td><td>93.36</td><td>97.75</td><td>1.48</td><td>48.35</td><td>33.54</td><td>0.87</td></tr><tr><td>50% (0011)</td><td>96.36</td><td>95.48</td><td>93.04</td><td>98.04</td><td>1.50</td><td>48.21</td><td>33.76</td><td>0.87</td></tr><tr><td>75% (1110)</td><td>96.28</td><td>95.43</td><td>95.23</td><td>99.01</td><td>1.38</td><td>25.37</td><td>33.17</td><td>0.46</td></tr><tr><td>75% (1101)</td><td>96.19</td><td>95.58</td><td>95.03</td><td>98.90</td><td>1.36</td><td>26.24</td><td>32.81</td><td>0.47</td></tr><tr><td>75% (1011)</td><td><strong>96.40</strong></td><td>95.74</td><td>95.09</td><td>98.75</td><td>1.35</td><td>25.31</td><td>32.86</td><td>0.46</td></tr><tr><td>75% (0111)</td><td>96.22</td><td>95.37</td><td>95.00</td><td>98.98</td><td>1.36</td><td>22.20</td><td>33.45</td><td>0.40</td></tr><tr><td>100% (1111)</td><td>96.24</td><td>95.48</td><td><strong>96.90</strong></td><td><strong>99.59</strong></td><td><strong>1.24</strong></td><td>8.71</td><td><strong>32.50</strong></td><td>0.16</td></tr></tbody></table>
<table><caption>**Table 7** Average results for medium workloads in non-cooperative and cooperative systems using *Real* renewable production. The bolditalic values indicate the best result for each column. The 0/1 notation shows which data center is aggressive (1) and cooperative (0)</caption><thead><tr><th rowspan="2"></th><th colspan="2">Bid</th><th colspan="3">QoS</th><th colspan="3">Money/Energy</th></tr><tr><th>Tasks (%)</th><th>Services (%)</th><th>Service (%)</th><th>Before due (%)</th><th>Slowdown</th><th>Benefits (×1000)</th><th>Energy wasted (%)</th><th>Ratio</th></tr></thead><tbody><tr><td>Cooperative</td><td>94.86</td><td>94.04</td><td><strong>95.91</strong></td><td><strong>99.38</strong></td><td><strong>1.27</strong></td><td><strong>88.94</strong></td><td><strong>34.63</strong></td><td><strong>1.61</strong></td></tr><tr><td>25% (1000)</td><td>95.18</td><td><strong>94.75</strong></td><td>91.92</td><td>96.17</td><td>1.48</td><td>84.38</td><td>36.35</td><td>1.53</td></tr><tr><td>25% (0100)</td><td><strong>95.39</strong></td><td>94.19</td><td>91.86</td><td>96.76</td><td>1.46</td><td>84.39</td><td>36.00</td><td>1.53</td></tr><tr><td>25% (0010)</td><td>95.21</td><td>93.84</td><td>91.39</td><td>95.64</td><td>1.56</td><td>83.33</td><td>36.27</td><td>1.51</td></tr><tr><td>25% (0001)</td><td>95.28</td><td>94.09</td><td>91.95</td><td>95.65</td><td>1.54</td><td>84.13</td><td>36.22</td><td>1.52</td></tr><tr><td>50% (1100)</td><td>95.08</td><td>94.72</td><td>92.58</td><td>97.30</td><td>1.45</td><td>63.20</td><td>36.02</td><td>1.14</td></tr><tr><td>50% (1010)</td><td>94.75</td><td>94.21</td><td>92.53</td><td>97.21</td><td>1.47</td><td>53.64</td><td>36.04</td><td>0.97</td></tr><tr><td>50% (1001)</td><td>94.96</td><td>94.24</td><td>92.95</td><td>97.76</td><td>1.47</td><td>54.61</td><td>36.13</td><td>0.99</td></tr><tr><td>50% (0110)</td><td>95.13</td><td>94.04</td><td>91.90</td><td>97.04</td><td>1.51</td><td>62.85</td><td>36.10</td><td>1.14</td></tr><tr><td>50% (0101)</td><td>95.31</td><td>94.14</td><td>92.50</td><td>97.36</td><td>1.48</td><td>64.84</td><td>35.96</td><td>1.17</td></tr><tr><td>50% (0011)</td><td>95.39</td><td>94.25</td><td>92.53</td><td>97.30</td><td>1.46</td><td>48.54</td><td>36.01</td><td>0.88</td></tr><tr><td>75% (1110)</td><td>94.74</td><td>94.04</td><td>93.82</td><td>98.39</td><td>1.39</td><td>37.68</td><td>35.58</td><td>0.68</td></tr><tr><td>75% (1101)</td><td>94.96</td><td>94.06</td><td>94.42</td><td>98.71</td><td>1.37</td><td>38.01</td><td>35.41</td><td>0.69</td></tr><tr><td>75% (1011)</td><td>95.03</td><td>94.13</td><td>94.47</td><td>98.67</td><td>1.36</td><td>27.59</td><td>35.35</td><td>0.50</td></tr><tr><td>75% (0111)</td><td>95.35</td><td>94.13</td><td>93.71</td><td>98.30</td><td>1.38</td><td>34.33</td><td>35.46</td><td>0.62</td></tr><tr><td>100% (1111)</td><td>94.86</td><td>94.04</td><td><strong>95.91</strong></td><td><strong>99.38</strong></td><td><strong>1.27</strong></td><td>16.88</td><td><strong>34.63</strong></td><td>0.31</td></tr></tbody></table>

data center. Similarly to the previous section, we created distinct combinations of aggressiveness for the non-cooperative configurations. Table 7 shows the results of this experiment. Again, we do not have a big variation in bid jobs and wasted energy. In addition, we have the same tendencies of Sect. 7.3.2 for QoS, benefits, and money/energy ratio.

An interesting result is obtained in the non-cooperative 25 % (0100) configuration. Even with data center 1 having the lowest total energy production (see Sect. 6.2), this configuration achieves slightly better results on tasks' QoS (before due and slowdown) than the other non-cooperative 25 % configurations. The explanation for this result comes from the data center 1 power production pattern. This data center power production has several moments with low production, resulting in an aggressive data center that is not too intrusive. So, the other data centers can receive a more fair share of jobs to run. On the other hand, the 25 % (0010) configuration, which makes data center 2 aggressive, has worse QoS and money results among the 25 % configurations. Data center 2 has a more constant power production, being present in more bids and reducing the share of the other data centers. This behavior is also present in Sect. 7.3.2, with data centers 1, 2, and 3 having a more constant pattern and data center 0 having a high variation. Therefore, the global results of the non-cooperative configurations depend on the impact of the aggressive data centers on the non-aggressive ones.

## 7.4 Discussion

After presenting all experiments, this section highlights the findings of our experimental campaigns. First, we could see in Sect. 7.1 a comparison between the MILP and heuristic algorithm. The MILP can find the optimal solution to the problem but with two main drawbacks. The first drawback is the time to find a solution using the linear model. In the worst case, MILP took 30 min to find a solution with a gap of 5 %, which demands high computation and expands more energy than the heuristic. It is inefficient to expend more energy solving the problem than executing users' jobs. The second drawback is that the linear model expects full workload knowledge, even of the jobs that will arrive in the marketplace, which is unrealistic. Someone can claim that a possible solution is reducing the time window size. However, this reduction will also decrease the MILP effectiveness and can increase the complexity of the model (e.g., start a new solution with jobs still running). For these reasons, our heuristic seems a good proposition. The gap between the MILP result and the heuristic goes from 38.58 % (best case) to 50.27 % (worst case), with less workload information (the heuristic only knows the jobs when they arrive) and faster (0.23 s in the slower solution and 0.05 s in the faster).

After that, we compared the heuristic with centralized and distributed data centers in Sect. 7.2. The objective is to prove that a distributed system can provide higher
availability than a centralized one in the renewable-only environments context. The results show that only the distributed data centers with different power productions achieve higher availability. A higher availability has two impacts. First, it overcharges the data centers, which can reduce the overall QoS. However, this is a problem only with large workloads. In medium and small workloads, the distributed system could equalize and even overcome the centralized results. The second impact is that the distributed configuration earned more money and wasted less energy, resulting in a higher efficiency measured by the money/energy ratio. While distributed data centers reduce the impact of intermittency by spreading data centers over different locations, a centralized data center could introduce energy storage to deal with it. However, these energy storages introduce other decision problems (e.g., when charging, when discharging, how to increase storage lifetime, etc).

Then, we discussed the impact of cooperation and competition in our heuristic in Sect. 7.3. Initially, we presented the effect of aggressive data centers on non-aggressive ones. In a marketplace where just one data center is aggressive, this aggressive data center takes more jobs, earning more money. The non-aggressive ones can take jobs exclusively when the aggressive has no space to run more jobs. However, we also demonstrated that this aggressive behavior only works with one aggressive. If there are two or more aggressive data centers, every data center receives less money than in the cooperative configuration. Therefore, it is safer to stay in the cooperative system. Thinking more globally about our metrics, we demonstrated in Tables 6 and 7 that the cooperative system is more efficient (higher money/energy ratio), gets more money to the marketplace (benefits), wastes slightly less energy, and provides better QoS than the non-cooperative propositions. More specifically, the cooperative achieves an improvement in QoS of 4.31% for services and 2.71% for tasks, earns 5.39% more money, and wastes 3.81% less energy than the competitive approach in real renewable energy production experiments. These results highlight the importance of data center fair play in this marketplace. We also demonstrated that the global metrics of the non-cooperative configurations are affected by the amount of “damage” that aggressive data centers can cause to the non-aggressive ones. Section 7.3.3 discusses this behavior. We saw that an aggressive data center with intermittent power production let some share of work to the non-aggressive ones. On the other hand, if the aggressive data center is always present (e.g., constant power production), it does not leave many jobs to the rest of the marketplace. Globally, this behavior outcomes in lower QoS and lower earned money.

# 8 Conclusion and future work

In order to respect the Paris Agreement definitions, the world must drastically reduce the GHG emissions of the different sectors. Regarding data centers, part of their emission comes from energy consumption. Therefore, every effort to reduce the energy-related emissions is important. A way to reduce these emissions is by migrating power production from fossil fuels to renewable energy sources, such as wind turbines and solar panels. In this context, this work proposes a marketplace with geo-distributed data centers only supplied by renewable energies. This marketplace implements a reverse auction process where the data centers bid for the user jobs. In addition, we proposed a linear model and a heuristic to solve the auction problem of this marketplace. Then, we presented an extensive experimental campaign, analyzing different aspects of this marketplace, such as a comparison between the linear model and the heuristic, a comparison between centralized and distributed architectures, and the impact of non-cooperative behaviors. Our results show that a geo-distributed data center architecture in a cooperative marketplace is more efficient, earns more money, wastes less energy, and provides higher QoS. In real renewable energy production experiments, the cooperative improves the QoS of the services in 4.31% and in 2.71% for tasks, earns 5.39% more money, and wastes 3.81% less energy than the competitive approach. Future works include the points presented in Sect. 4.5. Besides, it is possible to implement different algorithms to solve the problem. Finally, a transition strategy can be proposed to migrate from a non-renewable to our renewable-only marketplace.

**Funding** Open access funding provided by Université de Toulouse. This work was supported by the French Research Agency under the project DATAZERO (ANR-15-CE25-0012). This work received funding from the France 2030 program through PEPR CARECloud, managed by the French National Research Agency under grant agreement No. ANR-23-PECL-0003. Finally, experiments presented in this paper were carried out using the Grid’5000 testbed, supported by a scientific interest group hosted by Inria and including CNRS, RENATER and several Universities as well as other organizations. A CC-BY public copyright license has been applied by the authors to the present document and will be applied to all subsequent versions up to the Author Accepted Manuscript arising from this submission, in accordance with the grant’s open access conditions.

**Open Access** This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not
included in the article's Creative Commons licence and your intended
use is not permitted by statutory regulation or exceeds the permitted
use, you will need to obtain permission directly from the copyright
holder. To view a copy of this licence, visit http://creativecommons.
org/licenses/by/4.0/.

References

1. Core Writing Team, Lee, H., Romero, J. et al.: Climate change 2023: Synthesis report. contribution of working groups i, ii and iii to the sixth assessment report of the intergovernmental panel on climate change. Tech. Rep., Intergovernmental Panel on Climate Change, Geneva, Switzerland (2023)

2. Climate Action Tracker. 2100 warming projections: Emissions and expected warming based on pledges and current policies. *Warming Projections Global Update, November* (2022). Available at: https://climateactiontracker.org/global/temperatures/

3. Nations, U.: The Paris Agreement (2015). https://www.un.org/en/climatechange/paris-agreement. Publisher: United Nations

4. Olabi, A., Abdelkareem, M.A.: Renewable energy and climate change. Renew. Sust. Energy Rev. **158**, 112111 (2022)

5. Houghton, J.: Global warming. Rep. Prog. Phys. **68**, 1343 (2005)

6. Freitag, C. et al.: The climate impact of icf: A review of estimates, trends and regulations (2021). arxiv:2102.02622

7. UNESCO. Guide to measuring information and communication technologies (ict) in education (2009)

8. Rozite, V., Bertoli, E., Reidenbach, B.: Data centres and data transmission networks. Tech. Rep, International Energy Agency, Paris (2023)

9. Padhi, S., Subramanyam, R.: Uncertainty level-based algorithms by managing renewable energy for geo-distributed datacenters. Cluster Computing 1–18 (2024).

10. Rostirolla, G., et al.: A survey of challenges and solutions for the integration of renewable energy in datacenters. Renew. Sust. Energy Rev. **155**, 111787 (2022)

11. Katal, A., Dahiya, S., Choudhury, T.: Energy efficiency in cloud computing data centers: a survey on software technologies. Cluster Comp. **26**, 1845–1875 (2023)

12. Dong, H., Wang, L., Zhang, X., Zeng, M.: A two-stage stochastic collaborative planning approach for data centers and distribution network incorporating demand response and multivariate uncertainties. J. Cleaner Prod. **451**, 141482 (2024)

13. Duarte, J.L.R., Fan, N.: Operations of data centers with onsite renewables considering greenhouse gas emissions. Sust. Comp.: Inf. Syst. **40**, 100903 (2023)

14. Sharma, D., Rao, S.: Scheduling computing loads for improved utilization of solar energy. Sust. Comp.: Inf. Syst. **32**, 100592 (2021)

15. Pierson, J.-M., et al.: Datazero: datacenter with zero emission and robust management using renewable energy. IEEE Access **7**, 103209–103230 (2019)

16. Zhang, G., Zhang, S., Zhang, W., Shen, Z., Wang, L.: Distributed energy management for multiple data centers with renewable resources and energy storages. IEEE Trans. Cloud Comp. **10**, 2469–2480 (2020)

17. Wang, R., et al.: An optimal task placement strategy in geo-distributed data centers involving renewable energy. IEEE Access **6**, 61948–61958 (2018)

18. Zhou, S., Zhou, M., Wu, Z., Wang, Y., Li, G.: Energy-aware coordinated operation strategy of geographically distributed data centers. Int. J. Elect. Power Energy Syst. **159**, 110032 (2024)

19. Niu, L., Guo, Y.: for Computing Machinery, A. (ed.) Enabling reliable data center demand response via aggregation. (ed.for

Computing Machinery, A.) Proceedings of the Seventh International Conference on Future Energy Systems, 1–11 (2016)

20. Yu, Z., Guo, Y., Pan, M.: for Computing Machinery, A. (ed.) Coalitional datacenter energy cost optimization in electricity markets. (ed.for Computing Machinery, A.) Proceedings of the Eighth International Conference on Future Energy Systems, 191–202 (2017)

21. Sharghivand, N., Derakhshan, F., Siasi, N.: A comprehensive survey on auction mechanism design for cloud/edge resource management and pricing. IEEE Access **9**, 126502–126529 (2021)

22. Öner, E., Özer, A.H.: An energy-aware combinatorial auction-based virtual machine scheduling model and heuristics for green cloud computing. Sust. Comp.: Inf. Syst. **39**, 100889 (2023)

23. Khalil, M.I.K., et al.: Renewable-aware geographical load balancing using option pricing for energy cost minimization in data centers. Processes **10**, 1983 (2022)

24. Metwally, K., Jarray, A., Karmouch, A.: A distributed auction-based framework for scalable iaas provisioning in geo-data centers. IEEE Trans. Cloud Comp. **8**, 647–659 (2018)

25. Dibaj, S.R., Miri, A., Mostafavi, S.: A cloud dynamic online double auction mechanism (dodam) for sustainable pricing. Telecommun. Syst. **75**, 461–480 (2020)

26. Xu, J.: IEEE (ed.) A cloud computing resource allocation model based on combinatorial double auction. (ed.IEEE) 2016 3rd International Conference on Information Science and Control Engineering (ICISCE), 5–8 (2016)

27. He, K., Huang, C., Li, Z., Shi, A., Shi, J.: IEEE (ed.) An online auction for deadline-aware dynamic cloud resource provisioning. (ed.IEEE) 2016 IEEE 22nd International Conference on Parallel and Distributed Systems (ICPADS), 677–684 (IEEE, 2016)

28. Shi, W., Zhang, L., Wu, C., Li, Z., Lau, F.C.: An online auction framework for dynamic resource provisioning in cloud computing. ACM SIGMETRICS Perf. Eval. Rev. **42**, 71–83 (2014)

29. Wang, X., Sun, J., Huang, M., Wu, C., Wang, X.: IEEE (ed.) A resource auction based allocation mechanism in the cloud computing environment. (ed.IEEE) 2012 IEEE 26th International Parallel and Distributed Processing Symposium Workshops & PhD Forum, 2111–2115 (2012)

30. Bertsekas, D.P., Castanon, D.A.: A forward/reverse auction algorithm for asymmetric assignment problems. Compt. Opt. Appl. **1**, 277–297 (1992)

31. Aslam, S., et al.: A survey on deep learning methods for power load and renewable energy forecasting in smart microgrids. Renew. Sust. Energy Rev. **144**, 110992 (2021)

32. Lai, J.-P., Chang, Y.-M., Chen, C.-H., Pai, P.-F.: A survey of machine learning models in renewable energy predictions. Appl. Sci. **10**, 5975 (2020)

33. Vickrey, W.: Counterspeculation, auctions, and competitive sealed tenders. J. Finance **16**, 8–37 (1961)

34. Shih, D.-H., Lin, B., Huang, S.-Y.: Morvam: a reverse vickrey auction system for mobile commerce. Exp. Syst. Appl. **32**, 1113–1123 (2007)

35. Pfenninger, S., Staffell, I.: Long-term patterns of european pv output using 30 years of validated hourly reanalysis and satellite data. Energy **114**, 1251–1265 (2016)

36. Rienecker, M.M., et al.: Merra: nasa's modern-era retrospective analysis for research and applications. J. Climate **24**, 3624–3648 (2011)

37. Fürmann, T., Lechl, M., de Meer, H., Weidlich, A.: From computer systems to power systems: using stochastic network calculus for flexibility analysis in power systems. Energy Inf. **6**, 36 (2023)

38. Subkhankulova, D., Baklanov, A., McCollum, D.: Springer (ed.) Demand side management: a case for disruptive behaviour. (ed.Springer) Advanced Computational Methods for Knowledge Engineering: Proceedings of the 5th International Conference on

<figure><img src="image_11.png" /></figure>
Computer Science, Applied Mathematics and Applications, ICCSAMA 2017 5, 47–59 (2018)

39. Kell, A. J., Forshaw, M., McGough, A. S.: IEEE (ed.) Exploring market power using deep reinforcement learning for intelligent bidding strategies. (ed.IEEE) 2020 IEEE International Conference on Big Data (Big Data), 4402–4411 (2020)

40. Da Costa, G., Grange, L., De Courchelle, I.: Modeling, classifying and generating large-scale google-like workload. Sust. Comp.: Inf. Syst. **19**, 305–314 (2018)

41. Koochaksaraei, M.H.G., Haghighat, A.T., Rezvani, M.H.: An efficient cloud resource exchange model based on the double auction and evolutionary game theory. Cluster Computing **27**, 2291–2307 (2024)

42. Vasconcelos, M. et al.: IEEE (ed.) Optimal sizing of a globally distributed low carbon cloud federation. (ed.IEEE) 2023 IEEE/ ACM 23rd International Symposium on Cluster, Cloud and Internet Computing (CCGrid), 203–215 (2023)

43. Liu, S., Ma, X., Jia, Y., Liu, Y.: An energy-saving task scheduling model via greedy strategy under cloud environment. Wireless Commun. Mobile Comp. **2022**, 8769674 (2022)

**Publisher's Note** Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.