Minimizing Bottleneck Overload Risk in Online Edge Task Placement under Workload Uncertainty

1

Minimizing Bottleneck Overload Risk in Online Edge Task Placement under Workload Uncertainty

arXiv:2611.04425v1 [cs.DC] 3 Nov 2026

Lei Wang, Winston K.G. Seah, Gang Xu∗ , Xiaodong Xu and Baoqi Huang

Abstract—In edge computing, tasks must be placed on servers of finite capacity before workloads are realized, often with only workload means and variances known. An assignment balanced on expected load can still leave a server with more fluctuations than its residual capacity can absorb. Per-server risk constraints can enforce a prescribed overload tolerance but do not distinguish the assignments that meet it by how close the riskiest server comes to the limit. We show that, for independent tasks, placement preserves a period’s total variance and total residual capacity, and decides only how fluctuation, measured by standard deviation, is paired with residual capacity across servers. The risk ratio, the ratio of fluctuation to residual capacity, parameterizes a server’s worst-case overload probability over all aggregate workload distributions with given mean and variance. We minimize the largest risk ratio, attained at the risk bottleneck. Risk-Bottleneck Placement (RBP) places tasks in descending order of standard deviation, each on the server with the smallest post-assignment risk ratio, and refines the assignment with relocations and swaps within a finite per-period online budget. On small instances solved exactly by enumerating every assignment, minimizing the maximum expected utilization leaves the largest risk ratio 25.66–29.19% above its exact minimum on average, even with risk-minimizing tie-breaking, and the corresponding gap for RBP is 1.77–2.64%. In trace-derived multi-period simulations at two workload pressures, RBP reduces the worst-server overload probability by 26.0% and 18.0% relative to the best baseline and remains the lowest at every tested pressure and scale. Keywords—Edge computing, online task placement, load balancing, workload uncertainty, overload risk, risk-aware scheduling.

I. I NTRODUCTION Edge computing places computation close to users and data sources to reduce response latency, but each edge server operates with finite local capacity [1–3]. A placement decision must often be made before the actual computation demand of the arriving tasks is realized. The processing resources a task requires are uncertain before execution [4–6] and may become known only when the task completes [6]. What the scheduler can obtain in advance are low-order statistics of each task’s workload, typically its mean and variance [6, 7]. In an online system, the tasks of each decision period are placed using these moments together with the current server state before the workload realizations of the period are observed. A server that cannot complete its realized workload within the period carries the remainder into the next period as backlog. ∗ Corresponding author: Gang Xu (e-mail: csxugang@imu.edu.cn).

L. Wang, G. Xu, X. Xu and B. Huang are with the College of Computer Science, Inner Mongolia University, Hohhot 010021, China. W. K. G. Seah is with the School of Engineering and Computer Science, Victoria University of Wellington, Wellington 6140, New Zealand.

Under this information, balancing expected workload is not the same as balancing overload risk. After a placement, each server has a residual capacity, the capacity left after its backlog and the expected workload of its new tasks, and an aggregate workload fluctuation, measured by the standard deviation of the workload it has received. The residual capacity is the headroom available to absorb that fluctuation. We call the ratio of a server’s aggregate fluctuation to its residual capacity the server’s risk ratio. The larger it is, the more fluctuation the server must absorb with the headroom it has. A server can look well balanced in expectation while carrying more fluctuation than its headroom can safely absorb. Fig. 1 illustrates this on a small instance with 12 tasks and 3 servers, for which we enumerate all 312 = 531,441 complete assignments so that both assignments shown are exact optima. The assignment that minimizes the maximum expected utilization, which we call the expected-load optimum, gives the three servers nearly equal expected utilization. Yet S2 cannot absorb its fluctuation since its uncertainty margin, a safety margin proportional to its workload standard deviation, is larger than its residual capacity. The assignment that minimizes the largest risk ratio, the risk-ratio optimum, redistributes the same tasks so that expected utilization becomes uneven, with S1 carrying more expected load than S2 and S3, but fluctuation is better matched to the headroom of each server. The example raises a placement question that an expected-load criterion does not answer, that is, which server carries the largest fluctuation relative to the capacity left to absorb it and how a placement can make that ratio as small as possible. Classical scheduling rules operate on deterministic task sizes or estimated execution costs [8]. Chance-constrained programming [9, 10] and moment-based distributionally robust optimization [11–13] provide tools for turning probabilistic requirements into deterministic constraints, and the latter can derive such constraints from moment information without assuming a particular distribution. Work on mobile edge computing with uncertain processing cycles uses these tools to bring moment information into the decision. Li et al. [6] use the mean and variance of processing cycles to provide probabilistic deadline guarantees while minimizing user energy consumption, and Fan et al. [7] bound the computationoutage probability under an unknown workload distribution while also minimizing energy consumption. In both works, the probabilistic requirement determines which decisions are acceptable, and the optimized objective is energy consumption. Applied to placement, a requirement of this kind accepts every placement that keeps each server within the tolerance, however close its riskiest server comes to the limit. A scheduler may

2

Expected-load optimum

Risk-ratio optimum

S2’s uncertainty margin exceeds its residual capacity

every margin fits within its residual capacity

Load / server capacity

risk bottleneck

risk bottleneck capacity

1

0.5

0

S1

S2

S3

S1

expected utilization: nearly equal

expected load

S2

S3

expected utilization: uneven

uncertainty margin

residual capacity

Fig. 1. Expected-load optimum (left) and risk-ratio optimum (right) for one instance with 12 tasks and 3 servers, both obtained by enumerating every assignment. The expected-load optimum minimizes the maximum expected utilization and, among tied optima, minimizes the largest risk ratio. The risk-ratio optimum minimizes the largest risk ratio. Arrows mark the risk bottleneck, the server with the largest risk ratio. The uncertainty margin is a safety margin proportional to the server’s workload standard deviation.

instead balance a risk-adjusted load, which adds an uncertainty margin to the backlog and the expected workload of each server. Keeping this load within capacity marks the same boundary as a limit on the risk ratio, but two servers with the same risk-adjusted utilization can still have different risk ratios (Section III), so balancing risk-adjusted utilization does not directly minimize the largest one. Under the independent-task model considered in this work, server-level overload risk has a simple structure (Section IV). The total workload variance of a decision period is fixed by the arriving batch, and the total residual capacity is fixed by the batch and the current server state. Placement therefore cannot remove uncertainty or create headroom. It decides only how fluctuation is paired with residual capacity across servers. The risk ratio also has a distributionally robust meaning. Among all aggregate workload distributions with a server’s mean and variance, the largest overload probability is an increasing function of the risk ratio, which is the tight form of Cantelli’s inequality [11, 13]. We call the server with the largest risk ratio the risk bottleneck and take the bottleneck risk ratio, the largest risk ratio across servers, as the objective of per-period placement. Minimizing it therefore minimizes the largest worst-case overload probability across servers. A perserver risk tolerance defines a feasibility boundary but does not distinguish the placements within it. The bottleneck risk ratio ranks them by how close their riskiest server comes to the limit. Since a placement meets the tolerance if and only if its bottleneck risk ratio does not exceed a threshold set by the tolerance (Section III), every minimizer of the bottleneck risk ratio meets the tolerance whenever some placement does. For given residual capacities, the pairing view also shows that the bottleneck risk ratio is smallest when every server carries

fluctuation in proportion to its headroom. Tasks are indivisible, so this proportion cannot always be met exactly. On small instances with 3 and 4 servers, whose exact optima we obtain by enumerating every assignment, the bottleneck risk ratio of the optimum exceeds the proportional ideal by a median of 0.33% and 0.69%. Risk-Bottleneck Placement (RBP) builds on this structure in two stages that share one finite online budget. The construction stage processes tasks in descending order of workload standard deviation and places each on the server with the smallest postassignment risk ratio. The refinement stage then spends the remaining budget on one-task relocations and two-task swaps aimed at reducing the bottleneck risk ratio. The main contributions are as follows. Pairing view of server-level overload risk. Under task independence, the total workload variance and the total residual capacity of a decision period do not depend on placement, which acts only on how fluctuation is paired with headroom across servers. The risk ratio, a server’s aggregate fluctuation relative to its residual capacity, parameterizes the worst-case overload probability over all aggregate workload distributions with the given mean and variance, so minimizing the bottleneck risk ratio minimizes the largest such worst-case probability. The analysis also gives a lower bound on the bottleneck risk ratio of an assignment in terms of its residual capacities, attained if and only if every server carries fluctuation in proportion to its residual capacity. • Risk-Bottleneck Placement for finite-budget online assignment. RBP assigns each task to the server with the smallest post-assignment risk ratio, with tasks taken in descending order of standard deviation. It then refines the •

3

assignment with relocations and swaps aimed at reducing the bottleneck risk ratio, within a finite online budget that includes construction. The remainder of the paper is organized as follows. Section II positions this work relative to scheduling under workload uncertainty. Section III presents the system model and the risk formulation, and Section IV derives the structural properties. Section V describes RBP, Section VI reports the evaluation and Section VII concludes the paper. II. R ELATED W ORK A. Scheduling under Uncertainty in Edge Systems Scheduling and load-balancing heuristics for cloud and edge systems typically place tasks according to known or predicted execution costs or resource capacities [8, 14–17], and learning-based schedulers learn offloading and resourceallocation policies from observed system states [18–20]. A growing body of work in mobile edge computing models uncertainty explicitly, whether in offloading outcomes, in computing resources or in computation demand. Qu et al. [21] minimize the overall latency of offloaded tasks under a bounded number of uncertain offloading failures through min–max robust optimization, and Apostolopoulos et al. [22] study partial data offloading to UAV-mounted servers whose computing payoff is uncertain. Zhao et al. [23] schedule task batches semi-online on MEC nodes of uncertain performance, using historical latency statistics to adjust the effective capacity of node clusters. Closer to the present setting, other studies attach the uncertainty to the computation demand of tasks. Deng et al. [5] derive a closed-form expression for the average offloading success probability under uncertain processing cycles and intermittent communications and maximize this probability over offloading decisions. Statistical QoS guarantees [24] and moment-based probabilistic deadline and outage guarantees [4, 6, 7] attach uncertainty to the requirements of individual tasks or users, whereas Chen et al. [25] model uncertain task arrivals at the system level and minimize the energy-constrained expected system latency under the worstcase distribution of a data-driven ambiguity set. Executiontime uncertainty has also long been studied in real-time systems through probabilistic timing and schedulability analysis [26, 27], which analyzes timing distributions and deadline feasibility for a given task set and scheduling policy. Mixedcriticality scheduling associates tasks with several executiontime estimates and, when a high-criticality task overruns its lower estimate, reduces or suspends the service of lowercriticality tasks [28]. In our setting, the decision is the placement of a batch onto servers, and the question is how aggregate fluctuation is distributed against residual capacity across a fixed set of servers. B. Stochastic Packing, Overcommitment and Load Balancing Server-level capacity risk under random workloads is central to stochastic bin packing and cloud overcommitment. Cohen et al. [29] model overcommitment as bin packing with chance constraints, in which jobs arrive online and must be placed immediately. They show that, for independent Gaussian job sizes

or for distributionally robust families with given mean and diagonal covariance, each chance constraint becomes a submodular capacity constraint, and they give online placement algorithms with constant-factor guarantees, including a competitive ratio for First-Fit, that reduce the number of machines. Their submodular formulation captures risk pooling, whereby the safety buffer required per job decreases as more jobs share a machine. In the distributionally robust case, the resulting capacity condition adds to the aggregate mean a buffer proportional to the aggregate standard deviation, the same meanplus-buffer form as the risk-adjusted capacity condition of Section III. Exact methods for chance-constrained bin packing include branch-and-price under stochastic and distributionally robust item sizes [30]. More generally, Zhang et al. [31] reformulate distributionally robust chance-constrained binary programs under mean–covariance information as 0–1 secondorder cone programs and evaluate them on chance-constrained bin-packing instances. Yan et al. [32] place container batches onto machines that already carry load and minimize the cluster-wide Used Capacity at Confidence (UCaC). Under their Gaussian approximation, the UCaC of a machine is its aggregate mean plus a confidence-dependent multiple of its aggregate standard deviation, and the cluster objective sums this quantity over machines. Since the total mean over machines is fixed, minimizing the cluster UCaC amounts to minimizing the sum of per-machine standard deviations, which favors concentrating fluctuation on fewer machines. We instead minimize the largest ratio of aggregate fluctuation to residual capacity across servers, which, for given residual capacities, is smallest when fluctuation is proportional to residual capacity (Proposition 2). In virtualized datacenters, Wu et al. [33] schedule virtual machines online with overcommitment, raising utilization while keeping hotspot occurrence within a target probability, and a related study uses predicted utilization and Γ-robust optimization to select live migrations that keep each physical machine hotspot-safe with a desired probability [34]. In edge computing, Tang et al. [35] jointly learn per-node overbooking thresholds and container placement to maximize long-term provider profit, and Ma et al. [36] maximize platform profit subject to a per-node overload-probability constraint evaluated from task usage distributions. Stochastic server consolidation assigns services or jobs with random workloads to as few servers as possible [37, 38]. In real-time systems, Wang et al. [39] partition periodic tasks with probabilistic execution times onto multicore processors subject to a deadlinemiss probability bound, using execution-time distributions and period harmonicity to improve schedulability. Ren et al. [40] sort probabilistic real-time tasks by workload and assign them to processors one at a time so as to minimize the increase in a harmonic index. Stochastic load balancing shares the fixed-machine setting and a min–max objective. Kleinberg et al. [41] study assignments of stochastic jobs that minimize the expected maximum load and develop constant-factor approximations that summarize stochastic job sizes through effective-bandwidth measures. Stochastic load balancing has also been studied under other job-size distributions [42] and on unrelated machines [43].

4

In parallel-machine scheduling under uncertain processing times, Song and Leus [44] minimize the makespan under robust, chance-constrained and distributionally robust chanceconstrained models, whereas Novak et al. [45] maximize the probability that all jobs with normally distributed processing times finish by a common due date. Uncertainty-aware edge offloading optimizes quantities such as latency, energy, utility or offloading success probability, using robust, distributionally robust, probabilistic or prospecttheoretic formulations. In the stochastic packing, overcommitment and consolidation studies above, server-level capacity risk constrains placement or migration feasibility, and the objectives concern server count, utilization, UCaC, profit or migration cost, while in probabilistic real-time partitioning, execution-time distributions guide task-to-core partitioning to improve schedulability and resource utilization. Stochastic load balancing instead minimizes the expected maximum realized load, and parallel-machine scheduling under uncertainty addresses makespan under robust or chance-constrained models and the probability that all jobs meet a common due date. This paper directly optimizes a different server-level quantity. Given task moments, server capacities and the current backlog, it minimizes the largest worst-case overload probability across servers, expressed through the bottleneck risk ratio, by pairing aggregate fluctuation with residual capacity and improving that pairing within a finite online budget. III. S YSTEM M ODEL AND P ROBLEM F ORMULATION We consider online task placement in an edge computing system where the realized computational workload of a task is unknown when the placement decision is made. A placement that balances expected load may still leave one server with more workload fluctuation than its residual capacity can absorb. We therefore model both the expected workload and the aggregate fluctuation assigned to each server, conditioned on the backlog carried from previous periods.

Each task is indivisible and must be assigned to exactly one server. Let xij (t) ∈ {0, 1} indicate whether task i is assigned to server j in period t. A valid assignment satisfies X xij (t) = 1, ∀i ∈ Bt . (2) j∈M

The model covers only the placement of the current batch onto a fixed set of servers with finite capacities that stay constant across periods, which corresponds to resourceconstrained edge settings without elastic scaling. We do not model migration of executing work, preemption or communication delay. B. Servers and Backlog Server j has a fixed per-period processing capacity Cj > 0. Let Bj (t) ≥ 0 denote the unfinished workload already present at the beginning of period t. This backlog is known when the current decision is made. For an assignment X(t) = [xij (t)], the realized new workload of server j is X Aj (t) = xij (t) w ei . (3) i∈Bt

Server j processes at most Cj units of work during the period, and the remainder is carried forward:  + Bj (t + 1) = Bj (t) + Aj (t) − Cj , (4) where [z]+ = max{0, z}. Decisions in different periods are therefore coupled through backlog. Individual tasks from earlier periods are not rescheduled, and only their unfinished aggregate workload remains at the server that received them. The system is online across periods, while the tasks of one period are placed jointly as a batch. C. Aggregate Server State For a candidate assignment X, the aggregate mean workload of the current batch on server j is X µj (X) = xij µi , (5)

A. Tasks and Placement

i∈Bt

Consider a set of heterogeneous edge servers M = {1, . . . , m}. The system operates in discrete decision periods. At the beginning of period t, a batch Bt of n new tasks is available for placement. The realized workload of task i ∈ Bt is a nonnegative random variable w ei with E[w ei ] = µi ,

Var(w ei ) = σi2 .

(1)

At decision time the scheduler knows (µi , σi ) for every task of the current batch, but knows neither the realizations of the current batch nor any future batch. Estimation error in these moment inputs is outside the scope of this model. Task workloads are assumed mutually independent within a decision period, which makes the variance of colocated workloads additive and is used explicitly in the structural analysis below. No parametric workload distribution is assumed.

and, under the independence assumption, its aggregate variance is q X (6) vj (X) = xij σi2 , σj (X) = vj (X). i∈Bt

The expected residual capacity, after accounting for both the existing backlog and the expected workload of the current batch, is dj (X) = Cj − Bj (t) − µj (X). (7)   It is deterministic and equals E Cj − Bj (t) − Aj (t) , and we refer to it simply as the residual capacity in the remainder of the paper. The pair (dj , σj ) is the central server state in this formulation. Here dj is the headroom available to absorb deviations above the expected workload, and the aggregate standard deviation σj measures the fluctuation placed against that headroom.

5

D. Server-Level Risk Representation Write   pj (X) = Pr Bj (t) + Aj (t) > Cj

(8)

for the probability that server j cannot complete its assigned work within the period. When dj (X) > 0, Cantelli’s inequality gives σj2 (X) . σj2 (X) + d2j (X) (9) The bound depends on the aggregate fluctuation relative to the residual capacity, which motivates the server-level risk ratio   σj (X)/dj (X), dj (X) > 0, RRj (X) = 0, dj (X) = σj (X) = 0, (10)   +∞, otherwise.

A risk bottleneck, by contrast, is a server whose aggregate fluctuation is largest relative to its residual capacity. Let α ∈ (0, 1) be the prescribed per-server risk tolerance and r 1 κ= − 1. (14) α The risk-adjusted load of server j is

  pj (X) = Pr Aj (t) − µj (X) > dj (X) ≤

A server with RRj (X) = +∞ has no residual capacity left to absorb its fluctuation, whereas a server with dj (X) = σj (X) = 0 is loaded exactly to its capacity without fluctuation and cannot overload. For dj (X) > 0, the
right-hand side of Eq. (9) equals RRj2 (X)/ 1 + RRj2 (X) , which is increasing in RRj . A larger RRj means that the server carries more aggregate fluctuation relative to the capacity left to absorb it. The bound is tight when only the mean and variance of the aggregate workload are known. Let Pj (X) denote the set of all distributions of Aj (t) with mean µj (X) and variance σj2 (X). For dj (X) > 0, the worst-case overload probability over this set is   pj (X) ≜ sup Pr Bj (t) + Aj (t) > Cj P ∈Pj (X) P RRj2 (X) , = 1 + RRj2 (X)

(11)

where the supremum is approached by two-point distributions [11, 13]. When dj (X) ≤ 0, the supremum equals 0 if dj (X) = σj (X) = 0 and 1 otherwise, so Eq. (11) holds for every server with RRj2 /(1 + RRj2 ) read as 1 at RRj = +∞. The risk ratio is therefore a monotone parameterization of the worst-case overload probability of server j over the aggregate mean–variance ambiguity set Pj (X). The set Pj (X) constrains only the mean and variance of Aj (t), whereas the task model further requires Aj (t) to be a sum of independent nonnegative task workloads. The distributions that can actually arise form a subset of Pj (X), so pj (X) bounds pj (X) from above but need not be attained by the task workloads themselves. The bottleneck risk ratio of an assignment is RRmax (X) = max RRj (X), j∈M

(12)

and a server attaining it is a risk bottleneck. Since pj is increasing in RRj , the risk bottleneck is also a server with the largest worst-case overload probability and minimizing RRmax (X) minimizes maxj pj (X). Expected-load balancing asks how full a server is on average, as measured by the expected utilization Bj (t) + µj (X) uj (X) = . (13) Cj

b j (X) = Bj (t) + µj (X) + κσj (X), L

(15)

where κσj (X) is the uncertainty margin added to the backlog and the expected workload. For dj (X) > 0, the risk-adjusted utilization and the risk ratio are related by b j (X)
L dj (X) =1− 1 − κ RRj (X) , Cj Cj

(16)

b j (X) ≤ Cj holds if so the risk-adjusted capacity condition L and only if RRj (X) ≤ 1/κ. When dj (X) ≤ 0, each of the two conditions holds if and only if dj (X) = σj (X) = 0, so the equivalence holds for every server. Substituting RRj (X) ≤ 1/κ into Eq. (11) gives pj (X) ≤ pj (X) ≤

1 1/κ2 = = α. 2 1 + 1/κ 1 + κ2

(17)

The equivalence concerns feasibility, not the ordering of feasible servers. Inside the boundary, the risk-adjusted utilization also depends on the normalized residual capacity dj (X)/Cj , so two servers with the same risk-adjusted utilization can have different risk ratios, and an assignment that balances riskadjusted utilization need not minimize RRmax (X). An assignment is risk-feasible when every server satisfies the risk-adjusted capacity condition, equivalently when RRmax (X) ≤ 1/κ. The worst-case overload probability pj (X) is then at most α on every server. E. Problem Formulation Let Ft =



b j (X) ≤ Cj , ∀j ∈ M X: L

(18)

denote the set of risk-feasible assignments of the current batch. The placement problem in period t is min RRmax (X) X X s.t. xij = 1,

∀i ∈ Bt ,

(19)

j∈M

xij ∈ {0, 1},

∀i ∈ Bt , ∀j ∈ M.

The problem asks how the current batch should be placed so that the risk bottleneck carries as little fluctuation as possible relative to its residual capacity. By Eq. (11), this minimizes the largest worst-case overload probability across servers. The risk tolerance does not need to be imposed as a separate constraint. Since X ∈ Ft if and only if RRmax (X) ≤ 1/κ (Section III-D), every optimal solution of Eq. (19) is riskfeasible whenever Ft is nonempty. The tolerance α therefore determines whether an assignment can be certified at level α, but not which assignment minimizes RRmax .

6

Backlog and batch demand can leave Ft empty, in which case no assignment meets the tolerance. Since the model admits neither task rejection nor deferral, RBP still returns a complete assignment in such periods (Section V), and Section VI reports how often the returned assignments are risk-feasible. Problem (19) is NP-hard. With two servers of capacity C, no backlog and tasks whose P mean and variance both equal ai > p0, where Λ = a < C, the risk ratio i∈B
t i RRj (X) = µp j (X)/ C − µj (X) increases with µj (X), so RRmax (X) ≤ Λ/2/(C − Λ/2) holds if and only if X splits the ai into two sets of equal sum, which is the NP-complete PARTITION problem. IV. S TRUCTURAL P ROPERTIES The risk representation above has a structure that expected load alone does not show. Let X X X X Vt = σi2 , Dt = µi . (20) Cj − Bj (t)− i∈Bt

j∈M

j∈M

i∈Bt

A. Conservation under Placement Proposition 1. Under the independent-task model, every complete assignment X satisfies X X vj (X) = Vt , dj (X) = Dt . (21) j∈M

j∈M

Proof. Since every P P Ptask is2 assigned P 2to exactly one server, v (X) = x σ = σi = Vt , and likewise
iP Pj j Pj i ij i P d (X) = C − B (t) − j j µj (X) = j Cj − Pj j P j j B (t) − µ = D . □ t j j i i By Proposition 1, placement can neither reduce the total variance the model attributes to the batch nor create residual capacity. It determines only how aggregate fluctuation is paired with residual capacity across servers, and that pairing is the structural source of server-level risk imbalance. B. Proportional Risk Balancing The same structure yields an ideal lower bound on the bottleneck risk ratio for a given residual-capacity vector. Proposition 2. For an assignment X with dj (X) > 0 on every server, s Vt P , (22) RRmax (X) ≥ I(X) ≜ 2 j∈M dj (X)

The quantity I(X) depends on the residual capacities produced by the assignment itself, so it lower-bounds the bottleneck risk ratio of that assignment rather than the optimum of the discrete problem. By Eq. (23), the bottleneck risk ratio reaches this bound if and only if the fluctuation assigned to each server is proportional to the residual capacity available there. We refer to this proportionality as risk balance. Since tasks are indivisible and their means and variances move together, a scheduler cannot in general enforce that proportion exactly. C. Implication for Bottleneck-Oriented Search The bottleneck objective also restricts which servers can produce an immediate improvement. Suppose server b is the unique risk bottleneck under X, that is, RRb (X) > RRj (X) for all j ̸= b. A relocation of one task or a swap of two tasks that leaves server b untouched changes the risk ratios of at most two other servers and leaves RRb as it was, so the maximum cannot fall. Any one-step strict reduction of a unique bottleneck risk ratio must therefore involve the current bottleneck. This one-step property motivates prioritizing candidates involving the current risk bottleneck under a limited online search budget. V. R ISK -B OTTLENECK P LACEMENT The model and structural analysis in Sections III and IV show that server risk depends not only on expected load but also on how aggregate workload fluctuation is matched to the residual capacity of each server. Two properties guide the design of RBP. First, when the maximum bottleneck risk ratio is attained by a unique server, a single move that strictly reduces it must modify that server. Second, a placement, relocation or swap changes the aggregate state of at most two servers while all other server states remain unchanged. Risk-Bottleneck Placement (RBP) uses these properties in two stages. It first constructs a complete assignment by processing tasks with larger workload standard deviation earlier and placing each task on the server with the smallest postassignment risk ratio. It then spends the remaining online budget refining that assignment with relocations and swaps, evaluated first on the servers with the largest risk ratios. Candidate moves are evaluated incrementally from the servers they modify. All decisions are based on standard deviations and risk ratios, so the risk tolerance α does not enter the algorithm. It only determines whether the returned assignment is risk-feasible. Algorithm 1 summarizes the procedure.

with equality if and only if σm (X) σ1 (X) = ··· = . d1 (X) dm (X)

A. Risk-Guided Construction (23)

Proof. Let r = maxj σj (X)/dj (X) = RRmax (X), so that σ Pj (X)2 ≤ r dj (X) Pfor 2 every j. By Proposition 1, Vt = 2 σ (X) ≤ r j j j dj (X), which is Eq. (22). Equality requires σj2 (X) = r2 d2j (X) for every j. As σj (X), r and dj (X) are nonnegative, this is σj (X) = r dj (X), that is, Eq. (23). □

RBP sorts the tasks in non-increasing order of their standard deviations σi and places them one at a time. For a candidate server j, let µj and vj denote the aggregate mean and variance of the tasks already assigned to it in the current batch. If task i is tentatively placed on j, µ′j = µj + µi , q σj′ = vj′ ,

vj′ = vj + σi2 , d′j = Cj − Bj (t) − µ′j ,

(24)

7

Algorithm 1 Risk-Bottleneck Placement Require: Task batch Bt ; server states St = {Bj (t), Cj }j∈M ; online budget Tmax Ensure: Assignment X 1: τ ← N OW () + Tmax {deadline} 2: X ← R ISK G UIDED C ONSTRUCTION(Bt , St ) 3: while N OW() < τ do 4: committed ← B OTTLENECK R EFINE(X, Bt , St , τ ) 5: if not committed then 6: break 7: end if 8: end while 9: return X which give the post-assignment risk ratio RRj′ of the receiving server through Eq. (10). RBP places the task on the server with the smallest RRj′ . Algorithm 2 gives the construction procedure. Ordering. A task with a larger σi contributes more variance to whichever server receives it, so its placement can have a larger effect on the resulting risk profile. Processing such tasks earlier gives these higher-impact decisions access to a larger set of remaining server states. Risk feasibility of the receiver. A single insertion changes only the aggregate state of the receiving server, and by Section III-D the receiver satisfies the risk-adjusted capacity condition after the insertion if and only if RRj′ ≤ 1/κ. Whenever some server can receive the task within this condition, the server with the smallest RRj′ is therefore one of them, and the receiver rule needs no separate feasibility check. When no server can, the task is still placed on the server with the smallest RRj′ . The assignment then lies outside Ft , and refinement continues to reduce its bottleneck risk ratio. Alignment with the bottleneck objective. For nonnegative task demand, inserting a task cannot decrease the risk ratio of its receiver. Let rcur denote the largest server risk ratio before the insertion. If server j receives the task, the resulting system maximum is max{rcur , RRj′ }. Since rcur is common to all candidate receivers, minimizing RRj′ also minimizes the bottleneck risk ratio attained immediately after the insertion. Comparing RRj′ directly additionally distinguishes candidate Algorithm 2 Risk-Guided Construction Require: Task batch Bt ; server states St Ensure: Assignment X 1: µj ← 0, vj ← 0, ∀j ∈ M 2: Sort tasks by non-increasing σi 3: for each task i in the sorted order do 4: for each server j ∈ M do 5: Compute µ′j , vj′ , σj′ , d′j and RRj′ 6: end for 7: j ∗ ← arg minj∈M RRj′ 8: Assign task i to j ∗ ; update µj ∗ and vj ∗ 9: end for 10: return X

receivers when several of them lie below the current maximum. Relation to a risk-adjusted-utilization rule. A receiver rule that minimizes the post-assignment risk-adjusted utilization b ′ /Cj also selects a receiver within the risk-adjusted capacity L j b ′ /Cj ≤ 1 if and only if condition whenever one exists, since L j that condition holds. The two rules share this boundary, but by Eq. (16) they can rank the receivers inside it differently, because risk-adjusted utilization also depends on the normalized residual capacity d′j /Cj . The SG-σ baseline of Section VI uses the same task ordering as RBP with the risk-adjustedutilization rule, so the two constructions differ only in how they rank receivers. B. Bottleneck-Focused Refinement Sequential construction produces a complete assignment, but later placements can change which server is the risk bottleneck. RBP therefore spends the remaining online budget refining the constructed assignment. Instead of scanning local moves in an arbitrary order, it evaluates first the servers and tasks with the largest potential effect on the current bottleneck risk ratio. Acceptance criterion. RBP compares candidate assignments lexicographically by   X pj (X) , (25) Φ(X) = max pj (X), j∈M

j∈M

where pj (X) is the worst-case overload probability of Eq. (11). Since pj is increasing in RRj and X ∈ Ft if and only if RRmax (X) ≤ 1/κ, the first component already ranks every risk-feasible assignment ahead of every risk-infeasible one, so no separate feasibility term is needed. A candidate is a strict improvement when it reduces RRmax . Otherwise, it can be preferred only by reducing the second term at an unchanged bottleneck risk ratio. That term only distinguishes plateau candidates. Each invocation of Algorithm 3 commits at most one move. After a move is committed, the next invocation recomputes the server order from the updated assignment. Source-server selection. Source servers are visited in decreasing order of RRj . Since a server violates the risk-adjusted capacity condition if and only if RRj > 1/κ, servers that are not risk-feasible are visited first, the most severe violations earliest, followed by the remaining servers with the largest risk ratios. Victim ordering. For each task i assigned to source server a, RBP computes the decrease in the worst-case overload probability of the source obtained by removing that task,
gi = pa (X) − pa X \ {i} , (26) and examines the tasks in non-increasing order of gi . Under a finite budget, this ordering determines which candidates are reached first and thus where the search effort goes. Relocation. For task i on source server a, every server b ̸= a is examined as a destination. Within one victim, RBP

8

Algorithm 3 B OTTLENECK R EFINE: One Refinement Step Require: Current assignment X and its server aggregates; task batch Bt ; server states St ; deadline τ Ensure: true if one move is committed, false otherwise 1: for each source server a in S OURCE O RDER(X) do 2: if a contains no task from Bt then 3: continue 4: end if 5: plateau ← ∅ 6: Order the tasks on a by non-increasing removal gain gi Relocation stage for each task i in that order do 9: for each destination b ̸= a do 10: Evaluate moving i from a to b {keep it as plateau if it improves Φ but is not strict} 11: Periodically, if N OW() ≥ τ , return false 12: end for 13: if a strict candidate was found for i then 14: Commit the best such candidate; return true 15: end if 16: end for 17: Swap stage 18: for each task i in the same order do 19: for each destination b ̸= a containing at least one task do 20: h ← the minimum-σ task on b 21: Evaluate exchanging i and h {keep it as plateau if it improves Φ but is not strict} 22: Periodically, if N OW() ≥ τ , return false 23: end for 24: if a strict candidate was found for i then 25: Commit the best such candidate; return true 26: end if 27: end for 28: if plateau ̸= ∅ then 29: Commit plateau; return true 30: end if 31: end for 32: return false 7: 8:

evaluates all destinations and retains the best strict candidate according to (25). The move is committed for the first victim in removal-gain order that admits a strict relocation. The search is therefore first-improvement across victims and bestimprovement among destinations for a fixed victim. Swap. A relocation transfers the complete mean and variance contribution of task i to the destination and may therefore fail when no receiver can absorb the task without creating a worse state. A swap instead exchanges i with a resident task h of the destination, so the destination’s aggregate variance changes by σi2 − σh2 rather than by σi2 . RBP considers swaps only after no strict relocation is available for the current source. For each candidate destination, only its resident task with the smallest standard deviation is considered as the swap partner. This limits the pairwise neighborhood to one swap

candidate per destination and avoids returning a highly variable task to the source server that the search is attempting to relieve. Plateau handling. While relocation and swap candidates are evaluated, RBP also records candidates that are not strict but improve the comparison in (25). Such a candidate lowers the sum of per-server worst-case overload probabilities while leaving the bottleneck risk ratio unchanged. The best plateau candidate is committed only when the current source provides neither a strict relocation nor a strict swap. Secondary improvement therefore does not take priority over an available strict reduction of the bottleneck risk ratio. C. Incremental Evaluation A relocation or swap changes the aggregate mean and variance of two servers and leaves all other servers unchanged. RBP therefore maintains, for every server, its aggregate mean, variance, standard deviation, residual capacity and risk ratio. A candidate is evaluated by recomputing these quantities for the two affected servers while reusing the maintained state of the remaining servers. After a move is committed, the affected server states and task-membership information are updated before the next refinement step. Ties among candidate servers and tasks are broken by their indices. D. Online Execution Construction and refinement share a single finite online budget Tmax per decision period, which limits the solver-side computation for one placement decision. We set Tmax = 25 ms by default to test whether a placement decision can be computed within a few tens of milliseconds, and Section VI-G shows that the worst-server overload probability of RBP varies by at most 1.27% across budgets from 5 to 100 ms. Deadline checking is cooperative rather than preemptive. Construction runs to completion, and refinement checks the deadline periodically during candidate scanning. When the deadline is reached, RBP discards the candidate under evaluation and returns the current complete assignment. E. Complexity Sorting the batch by σi costs O(n log n), and evaluating all m candidate receivers for each of the n tasks costs O(nm). During refinement, the servers are ordered by their current risk ratios, and the tasks of each visited source server are ordered by their removal gains. Across all visited sources, each task can be examined as a victim, and each victim considers at most m − 1 relocation destinations and, when no strict relocation is available for the current source, at most m−1 swap destinations. A complete refinement scan therefore examines at most O(nm) relocation and swap candidates, in addition to the ordering costs. Additional state updates are required only after a move is committed. The actual number of refinement steps executed in each decision period is limited by the finite online time budget.

9

VI. P ERFORMANCE E VALUATION We evaluate RBP from four perspectives. On small instances whose exact optima are obtained by enumerating every assignment, we test whether the structure identified in Section IV appears in exact risk-ratio optima and measure how closely each online method approaches the exact optimum. The main multi-period experiments compare RBP with expected-load and risk-aware baselines at two workload pressures. Ablations quantify what refinement adds to the risk-guided construction and what the bottleneck-focused visiting order adds within refinement. Load, scale and budget experiments examine how the observed behavior changes outside the default condition. Each experiment family draws its own instances and random streams. Within a family all methods see identical instances, identical capacities and identical evaluation streams, so the comparisons reported below are made within a family, and absolute values are not compared across families. A. Experimental Setup 1) Trace-Derived Workload Construction: We use Google Cluster Trace 2019 [46, 47] to construct empirical tasklevel workload profiles rather than to replay a datacenter workload timeline. The trace supplies the heterogeneity of workloads across tasks and the empirical distribution of each task’s workload, while the batch process, server capacities, backlog evolution and placement decisions follow the model of Section III and the configuration below. We take the jobinstance usage records of cell a over hours 24 to 48 of the trace. Each task is one job instance, and each observation is its average normalized CPU usage over a complete 300second window. Since all windows have the same duration, an observation is proportional to the work the task performs in its window, and one decision period therefore represents a five-minute workload interval. We retain the tasks with at least 12 such observations and a positive mean and variance, and the retained observations of a task define its empirical workload distribution. Workloads, capacities and backlog are expressed in a common normalized work unit. Some tasks in the retained pool cannot satisfy the riskadjusted capacity condition on any server at the capacities calibrated by Eq. (27), even when placed alone. A batch that contains such a task admits no risk-feasible assignment. To exclude such tasks, we remove the tasks with the largest risk-adjusted size µi + κσi . The removed fraction was fixed before the formal evaluation by a rule that involves no placement method. Among prespecified fractions, it is the smallest for which, in each of the eight combinations of m ∈ {5, 10, 20, 50} and ρR ∈ {0.90, 0.95}, at most 1% of 1,000 sampled batches contain such a task. The rule selects 2%. The removed tasks account for 28.6% of the total mean and 78.6% of the total variance of the unfiltered pool, and 954,211 tasks remain. Capacities are calibrated by Eq. (27) on batches drawn from the retained pool, so the workload pressure after trimming is still set by ρR . Unless stated otherwise, each period samples a batch of n = 100 tasks from this pool without replacement, and all methods receive the same batch. The exact-small experiments

use smaller batches from the same pool. All placement methods observe only the moments (µi , σi ) at decision time, as assumed in Section III, and never the realized workload of the current period. The realized workload of a task is drawn uniformly with replacement from its retained observations, independently across tasks, and both the Monte Carlo samples used to estimate overload probabilities and the realized path used to update backlog are generated in this way. Since µi and σi2 are the mean and variance of the same observations, the scheduler receives the exact moments of this resampling distribution, and the experiments introduce no momentestimation error. This construction preserves the empirical workload distribution of each retained task while matching the independent-task model of Sections III and IV. Cross-task correlations in the original trace are not reproduced. 2) System Configuration: The default system contains m = 10 heterogeneous servers and runs for T = 100 consecutive periods, with backlog propagated by Eq. (4) from an empty initial state. Server capacities are generated once at the beginning of a run and stay fixed for that run. Relative capacities are perturbed independently within ±10% and normalized to preserve the prescribed total. Workload pressure is controlled through the robust load ratio ρR . For the T batches of one run, the total capacity is calibrated as   s X T 1 X X µi + κ m σi2  T t=1 X i∈Bt i∈Bt . (27) Cj = ρR j∈M

The bracketed term is the risk-adjusted demand of a batch when its total variance Vt is split evenly across the m p servers, since each server then carries an uncertainty margin κ Vt /m √ and the margins sum to κ mVt . The robust load ratio ρR is thus the ratio of this demand, averaged over the run, to the total capacity, and a larger ρR leaves less spare capacity for the same workload, that is, higher workload pressure. The calibration is performed before the run and gives all methods the same capacities. Within the run, each placement decision uses only the current batch and the current server state. The exact-small instances consist of a single batch and are calibrated by the same expression with T = 1 and ρR = 0.90. Table I summarizes the default configuration. The two main conditions use ρR ∈ {0.90, 0.95}. The risk tolerance is fixed at α = 0.15 before the evaluation runs, which gives κ = 2.3805 through Eq. (14). The same κ is used by the three risk-aware baselines described below, RG, SG-σ and RA-FF, and by the capacity calibration of Eq. (27), whereas RBP does not use α in its placement decisions (Section V). Unless stated otherwise, each condition contains 30 independent runs, and RBP uses the 25 ms finite online budget of Section V-D. 3) Baselines: We compare RBP with four rule-based baselines and one auxiliary local-search method. Since closely related published methods differ in objective or decision model (Section II), the baselines are chosen to separate the placement principles relevant to the present problem. DG represents expected-load balancing, as in load-balancing heuristics that place tasks according to known or predicted execution costs or

10

TABLE I D EFAULT EXPERIMENTAL CONFIGURATION . Parameter

Symbol

Value

Number of servers Capacity heterogeneity Batch size per period Period length Periods per run Independent runs Target robust load ratio Risk tolerance Robustness coefficient Monte Carlo samples per period Online budget of RBP

m Cj n – T R ρR α κ S Tmax

10 ±10% around the mean 100 300 s 100 30 0.90, 0.95 0.15 2.3805 10,000 25 ms

utilization maxj uj (X) by local search, starting from an expected-load construction, within a soft budget of 100 ms, compared with the 25 ms default of RBP. We include it to examine whether search effort under the expected-load objective produces the same risk behavior. 4) Metrics and Evaluation Protocol: The primary metric is the empirical counterpart of the bottleneck objective of Eq. (12). For each period we draw S = 10,000 workload realizations by independently resampling each task’s tracederived workload profile and estimate the overload probability of server j as " # S X 1X (s) 1 Bj (t) + xij (t) w ei > Cj . (28) pbj (t) = S s=1 i∈Bt

resource capacities [14, 15]. RG and SG-σ use the mean-plusstandard-deviation risk adjustment that underlies momentbased capacity conditions [6, 29], and SG-σ additionally shares the task order of RBP. RA-FF adapts the ordering and first-fit structure of [6], and Exp-LS is an auxiliary control that applies additional search to an expected-load objective. All of them observe the same task information and server state, namely the moments of the current batch, the current backlog and the server capacities, and none observes a realization. Each rule below is described by the order in which it processes tasks, the criterion by which it selects a receiver, the feasibility condition it applies and its behavior when no receiver satisfies that condition. DG (deterministic greedy). Tasks are processed in input order, and each task is placed on the server with the smallest post-assignment expected utilization (Bj + µj + µi )/Cj . DG does not read σi and applies no feasibility condition. • RG (robust greedy). Tasks are processed in input order, and each task is placed on the server with the smallest b ′ /Cj . No feapost-assignment risk-adjusted utilization L j sibility condition is applied. • SG-σ. Tasks are processed in non-increasing order of σi , and the receiver criterion is that of RG. SG-σ shares its task ordering with the construction of RBP and differs from it only in the receiver rule, so it shows what the σ ordering provides without the receiver rule and the refinement stage of RBP. • RA-FF (risk-adjusted first-fit). This baseline adapts the ordering and first-fit placement of the energy-minimized solution with probabilistic deadline guarantee (EPD) in [6]. Tasks are ordered by non-decreasing µi + κσi , which is the ordering key of [6] without its task-deadline normalization, since this model has no task-level deadlines. Each task is placed on the first server, scanned by index, that satisfies the risk-adjusted capacity condition b ′ ≤ Cj after the insertion, as in the first-to-fit placement L j of [6]. If no server satisfies the condition, the task goes to the one with the smallest resulting risk-adjusted load, since tasks cannot be rejected. The risk-adjusted capacity condition thus serves only as a feasibility test and does not rank the servers that pass it. • Exp-LS. This method minimizes the maximum expected •

The period-level value is pbmax (t) = max pbj (t), j∈M

(29)

and we average it over the 100 periods of a run. The maximum is taken across servers within each period before averaging over periods, so the metric evaluates the worst-server overload outcome corresponding to the bottleneck objective. The objective minimizes the largest worst-case overload probability over the aggregate mean–variance ambiguity sets of Section III-D, and the primary metric tests whether this also lowers the worstserver overload probability under the trace-derived workload distributions. We also report the probability that at least one server overloads in a period, the fraction of periods whose returned assignment belongs to Ft , the normalized system P P backlog j Bj (t)/ j Cj measured before the decision and the largest normalized single-server backlog. The risk-feasible rate records how often the moment-based guarantee of Eq. (17) certifies the returned assignment at level α for every aggregate distribution with the given moments. The two overload probabilities are estimated from the Monte Carlo samples, whereas backlog evolves along one realized path through Eq. (4). Overload probabilities and backlog thus measure different consequences of the same decision. Runtime is wall-clock time over the complete solver call. Since construction runs to completion and refinement checks the deadline only periodically (Section V-D), we report the median, the 99th percentile, the maximum and the observed fraction of periods exceeding 25 ms. All methods within the same run and period use the same sampled task batch, workload realizations and evaluation streams. Per-period values are averaged within a run, and reported entries are means over the 30 runs. The “±” term shown for the primary metric is the standard deviation across runs. For the primary metric in the main experiment, we compare RBP with RG, SG-σ and RA-FF on the 30 paired run-level values at each of the two pressures. Each comparison uses a two-sided Wilcoxon signed-rank test, and the six pvalues are adjusted with the Holm procedure. A difference is called statistically significant when its adjusted p-value is below 0.05. The protocol, the solver, the baselines, the metrics, the statistical tests and the seed derivation were frozen before these runs, and the seeds are disjoint from those used during

11

development. All methods are implemented in Python 3.10 with NumPy and executed in a single process on the same machine, which has an AMD Ryzen 9 8945HX processor and 32 GB of RAM and runs Windows 11. B. Structure and Optimality on Enumerated Small Instances Small instances allow us to answer two questions that the main scale cannot. The first is whether the structure derived in Section IV appears in exact risk-ratio optima, and the second is how far each online method remains from that optimum. Each instance has n = 12 tasks and m ∈ {3, 4} servers with no initial backlog, with 20 held-out instances per server count. Every complete assignment is enumerated, which yields the exact minima of both RRmax (X) and maxj uj (X). Each objective is determined by a single server, so either can be attained by several assignments. We therefore define the expected-load optimum as the assignment with the smallest RRmax among those minimizing maxj uj (X), and the risk-ratio optimum X ⋆ as the assignment with the smallest maxj uj (X) among those minimizing RRmax (X). Each optimum is thus chosen to be as good as possible on the other criterion. Since enumeration is independent of any heuristic, the structural quantities below are properties of the placement problem itself. The risk-ratio optimum is typically close to the proportional ideal. Table II summarizes the structure. The excess of RRmax (X ⋆ ) over the ideal I(X ⋆ ) of Eq. (22) has median 0.33% for m = 3 and 0.69% for m = 4, so the proportional balance of Eq. (23) is nearly attainable even though tasks are indivisible. The m = 4 instances are less uniform, with a mean of 3.57% and a largest value of 27.35%. Expected-load balance and risk balance identify different assignments and different critical servers. Even with ties resolved in its favor, the expected-load optimum carries an RRmax that exceeds that of the exact risk-ratio optimum by 25.66% for m = 3 and 29.19% for m = 4 on average. The two criteria also disagree about which server is critical. The server with the largest expected utilization is also a risk bottleneck in only 36.18% (m = 3) and 22.65% (m = 4) of an instance’s risk-feasible assignments on average, so expected load does not reliably identify the server that determines the risk objective. Relative to the expected-load optimum, the riskratio optimum raises the maximum expected utilization by 22.18% for m = 3 and 27.58% for m = 4. The two criteria are therefore different placement objectives, and each optimum performs worse under the other criterion. RBP stays close to the exact risk-ratio optimum. Table III compares the online methods with the enumerated risk-ratio optimum. RBP has mean gaps of 2.64% and 1.77%, and its gap is at most 5% on 95% and 100% of the instances. SG-σ, the best of the compared greedy rules here, reduces the mean gap from 20.63% and 26.87% for RG to 7.57% and 8.45%. One m = 4 instance admits no risk-feasible assignment at all, and RBP returns a risk-feasible assignment on every instance that admits one. C. Main Performance We compare all methods under the default configuration at the two main pressure points.

TABLE II S TRUCTURAL RESULTS ON ENUMERATED SMALL INSTANCES . Quantity

m=3

m=4

RRmax (X ⋆ )/I(X ⋆ ) − 1, mean RRmax (X ⋆ )/I(X ⋆ ) − 1, median RRmax excess of the expected-load optimum maxj uj excess of X ⋆ Bottleneck overlap

0.53% 0.33% 25.66% 22.18% 36.18%

3.57% 0.69% 29.19% 27.58% 22.65%

X ⋆ is the risk-ratio optimum and I(X ⋆ ) its proportional ideal from Eq. (22). Excess is relative to the exact minimum of the same quantity. Overlap is the fraction of an instance’s risk-feasible assignments in which the server with the largest expected utilization is a risk bottleneck. Entries other than the median are means over instances. For m = 4, overlap is averaged over the 19 instances that admit a risk-feasible assignment. TABLE III D ISTANCE FROM THE EXACT RISK - RATIO OPTIMUM ON HELD - OUT SMALL INSTANCES . M EAN GAP IS THE MEAN OVER INSTANCES OF ⋆ ⋆ RRmax /RRmax − 1, WHERE RRmax IS THE EXACT MINIMUM . T HE COLUMN “≤ 5%” GIVES THE FRACTION OF INSTANCES WITH A GAP OF AT MOST 5%, AND “F EAS .” GIVES THE FRACTION ON WHICH THE RETURNED ASSIGNMENT IS RISK - FEASIBLE . O NE m = 4 INSTANCE ADMITS NO RISK - FEASIBLE ASSIGNMENT. m=3 Method

Mean gap

DG RG SG-σ RA-FF Exp-LS RBP

36.68% 20.63% 7.57% 13.73% 29.12% 2.64%

≤ 5%

m=4 Feas.

Mean gap

≤ 5%

Feas.

0% 5% 10% 50% 40% 100% 15% 90% 0% 15% 95% 100%

38.33% 26.87% 8.45% 18.45% 34.78% 1.77%

0% 0% 30% 20% 0% 100%

10% 20% 95% 55% 5% 95%

RBP attains the lowest worst-server overload probability at both pressures. Table IV reports the main multi-period results. At ρR = 0.90 RBP reaches 2.299% against 3.105% for SG-σ, 3.147% for RG and 3.313% for RA-FF, which are reductions of 26.0%, 26.9% and 30.6%. At ρR = 0.95 it reaches 2.941%, reducing the same metric by 18.0%, 23.9% and 23.5% against the same three baselines. All six paired comparisons are statistically significant after Holm correction. Accounting for fluctuation has a larger effect than σordering. Two comparisons among the baselines separate the ingredients that RBP also uses. DG, which ignores fluctuation, exceeds RG on the primary metric by 39.97% and 41.90% at the two pressures. Adding the σ-descending order to the same receiver rule, which is the step from RG to SG-σ, reduces the primary metric by 1.3% and 7.2% while raising the riskfeasible rate from 71.03% to 92.13% and from 38.47% to 65.37%. Since SG-σ already uses that ordering, the reductions reported above for RBP over SG-σ are obtained through the receiver rule and the refinement of RBP. Despite a 100 ms budget, four times that of RBP, ExpLS reaches worst-server overload probabilities of 4.283% and 5.368%, only 2.8% and 2.1% below DG, against 2.299% and 2.941% for RBP. Additional search under the expected-load objective thus does not reproduce the risk reduction of RBP, and that reduction is not explained by search time alone. Section VI-G further shows that the primary metric of RBP changes little between budgets of 5 and 100 ms. RBP also has the lowest probability that any server

12

TABLE IV M AIN RESULTS OVER 30 RUNS . T HE PRIMARY METRIC IS REPORTED AS MEAN ± STANDARD DEVIATION ACROSS RUNS , AND THE REMAINING ENTRIES ARE MEANS . OVERLOAD PROBABILITIES AND RISK - FEASIBLE RATES ARE IN PERCENT.

ρR

Method Worst-server overload Any-server overload Risk-feasible rate Total backlog Max-server backlog

DG RG SG-σ 0.90 RA-FF Exp-LS RBP

4.404 ± 0.515 3.147 ± 0.574 3.105 ± 0.522 3.313 ± 0.590 4.283 ± 0.509 2.299 ± 0.523

18.327 18.634 18.426 17.355 18.188 11.386

18.83 71.03 92.13 94.93 22.73 96.50

0.004558 0.003449 0.004487 0.003398 0.004552 0.002917

0.043672 0.042614 0.042974 0.032776 0.043281 0.028122

DG RG SG-σ 0.95 RA-FF Exp-LS RBP

5.486 ± 0.655 3.866 ± 0.558 3.587 ± 0.561 3.847 ± 0.543 5.368 ± 0.663 2.941 ± 0.557

22.879 18.834 23.213 19.354 22.724 14.044

4.80 38.47 65.37 73.57 5.60 78.63

0.006035 0.004693 0.006056 0.004194 0.006003 0.003744

0.056802 0.043992 0.056790 0.040949 0.056238 0.036658

overloads. The corresponding probabilities are 11.386% and 14.044%, which are 34.4% and 25.4% below the best compared baseline on this metric at ρR = 0.90 and 0.95, respectively. RBP also attains the highest risk-feasible rate at both pressures. At ρR = 0.90 it returns a risk-feasible assignment in 96.50% of periods against 94.93% for RA-FF and 92.13% for SG-σ, and at ρR = 0.95 the values are 78.63%, 73.57% and 65.37%. RBP has the lowest backlog at both pressures. Relative to RA-FF, the best baseline on both backlog measures, RBP lowers total backlog by 14.2% and 10.7% and maximum singleserver backlog by 14.2% and 10.5%, so its risk reduction is not accompanied by higher backlog in the tested conditions. A lower worst-server overload probability does not by itself imply less backlog, however, since SG-σ has a lower worstserver overload probability than RA-FF at both pressures but more backlog than both RA-FF and RG. D. Ablation Study We use two ablations to distinguish what refinement contributes from what the bottleneck-focused visiting order contributes. Construction only runs the risk-guided construction of Section V-A and returns its assignment without refinement. Random-order scan keeps that construction, the acceptance rule of Eq. (25), the relocation and swap stages and the commit rule of the refinement stage, but visits source servers and their tasks in random order instead of in decreasing order of risk ratio and removal gain. Refinement further reduces risk and improves feasibility, with the larger feasibility gain under higher load. Table V reports both comparisons. Starting from the same constructed assignment, refinement lowers the worst-server overload probability by a further 5.28% at ρR = 0.90 and 2.30% at ρR = 0.95, and raises the risk-feasible rate from 92.70% to 96.17% and from 68.40% to 79.63%, the latter an increase of 11.23 percentage points. The bottleneck-focused order lowers risk relative to a random order. Relative to the random-order scan, RBP lowers the worst-server overload probability by 1.39% at ρR = 0.90

TABLE V A BLATION RESULTS UNDER THE MAIN CONFIGURATION . R ISK IS THE WORST- SERVER OVERLOAD PROBABILITY, AND EACH COMPARISON IS A SEPARATE PAIRED EXPERIMENT. Risk (%)

Feasible rate (%)

Comparison

ρR

RBP

Variant

RBP

Variant

Construction only Construction only Random-order scan Random-order scan

0.90 0.95 0.90 0.95

2.298 3.015 2.304 3.003

2.426 3.086 2.337 3.099

96.17 79.63 96.13 80.00

92.70 68.40 96.03 79.80

and 3.09% at ρR = 0.95, while the feasible rates differ by 0.10 and 0.20 percentage points. E. Load Sensitivity We vary ρR from 0.80 to 0.98 at the default system size to test whether the advantage of RBP persists outside the two main operating points. The advantage persists across the tested pressure range. As Fig. 2(a) shows, the absolute overload probability rises with pressure for every method. RBP has the lowest worst-server overload probability at all five load levels, and its reduction relative to SG-σ ranges from 15.3% to 26.8% across the tested range. Risk feasibility decreases as ρR grows. RBP is risk-feasible in 99.80%, 99.50%, 95.73%, 78.80% and 59.53% of periods across the five levels. At ρR = 0.80 and 0.85, RBP, SG-σ and RA-FF all remain above 99%, and the differences become larger at the three heavier levels, where RA-FF reaches 52.50% and SG-σ 44.27% at the highest pressure. F. Scalability We scale the number of servers and tasks proportionally, m ∈ {5, 10, 20, 50} with n = 10m, to test whether the relative behavior persists as the placement problem grows. Task density per server is held constant and capacity is recalibrated for each configuration by Eq. (27). The ordering of the methods is preserved as the system grows. As Fig. 2(b) shows, the absolute worst-server overload

13

Worst-server overload probability (%)

DG

SG-σ

RG

RA-FF

8

8

6

6

4

4

2

2

0

0.80

0.85

0.90

Robust load ratio ρR

0.95

0.98

0

5

(a) Load sensitivity (m = 10)

Exp-LS

RBP

10

20

50

Number of servers m (log scale) (b) Scalability (n = 10m, ρR = 0.90)

Fig. 2. Worst-server overload probability under varying workload pressure and system scale. Each point is the mean over 30 runs. (a) Robust load ratio ρR from 0.80 to 0.98 with m = 10 servers. (b) m ∈ {5, 10, 20, 50} servers with n = 10m tasks per period at ρR = 0.90, with capacity recalibrated for each size.

probability increases with scale for every method, while RBP retains the lowest value at every tested size, with reductions of 13.9%, 21.5%, 13.5% and 11.8% relative to SG-σ. The risk-feasible rates of RBP across the same four scales are 90.27%, 96.30%, 98.63% and 98.73%, above SG-σ at 86.27%, 91.53%, 96.03% and 98.00% and RA-FF at 87.70%, 94.73%, 98.10% and 98.57%. DG shows the opposite trend, with its risk-feasible rate falling from 38.70% at m = 5 to 0.07% at m = 50. G. Runtime and Budget Sensitivity RBP is designed for a finite online decision budget. We report its per-period running time under the two main conditions, and then vary the budget itself to examine whether additional search time changes the primary metric. As Table VI shows, the median runtime is 24.55 and 24.57 ms and the 99th percentile is 24.67 ms in both conditions. One of the 3000 periods in each condition exceeds the nominal budget, by at most 0.15 ms, which is consistent with the cooperative deadline of Section V-D. The 25 ms budget is therefore a practical finite online budget rather than a hard real-time upper bound. At m = 5 the median runtime is about 6.01 ms, whereas for m ≥ 10 it is about 24.56–24.57 ms. Algorithm 1 stops early only when refinement finds no committable move, so smaller instances can terminate well before the budget, while the larger configurations typically use nearly the full search horizon. At the two main pressures, the construction stage of RBP has a median runtime of 0.54–0.71 ms per period, comparable to the 0.25–0.76 ms of the four single-pass baselines, so nearly all of the 25 ms budget is spent on refinement. Exp-LS has a median runtime of 104.44–104.89 ms under its soft 100 ms budget. Table VII varies the nominal budget from 5 to 100 ms. Across this range the primary metric varies by 1.27% of its level at ρR = 0.90 and 0.67% at ρR = 0.95, so over the tested

TABLE VI RBP RUNTIME IN THE MAIN EXPERIMENT, 3000 PERIODS PER CONDITION . ρR

Median (ms)

p99 (ms)

Max (ms)

> 25 ms

0.90 0.95

24.55 24.57

24.67 24.67

25.15 25.04

0.033% 0.033%

TABLE VII RBP BUDGET SENSITIVITY: WORST- SERVER OVERLOAD PROBABILITY (%). A LL BUDGETS ARE RUN ON THE SAME INSTANCES , WHICH ARE DRAWN SEPARATELY FROM THOSE OF TABLE IV, SO ABSOLUTE VALUES ARE NOT DIRECTLY COMPARABLE WITH TABLE IV. Budget (ms) 5 10 25 50 100

ρR = 0.90

ρR = 0.95

2.306 2.298 2.291 2.320 2.295

3.164 3.162 3.160 3.145 3.143

range the result has limited sensitivity to the online budget. We use 25 ms as the practical default. VII. C ONCLUSION This paper studied online task placement on edge servers when only the mean and variance of each task’s workload are known at decision time, a setting in which balancing expected load need not balance overload risk. For independent tasks, placement changes neither the total workload variance nor the total residual capacity of a period, only how fluctuation is paired with headroom across servers. The ratio of a server’s fluctuation to its residual capacity captures this pairing and parameterizes the server’s worst-case overload probability over all aggregate workload distributions with the given mean and variance. Minimizing the largest ratio relieves the server that forms the risk bottleneck. RBP uses this structure in two stages that share one finite online budget. It processes tasks in descending order of

14

standard deviation, assigning each to the server with the smallest post-assignment risk ratio, and then refines the resulting assignment through relocations and swaps aimed at reducing the bottleneck risk ratio. On small instances solved exactly by enumerating every assignment, even the least risky expected-load optimum carries a bottleneck risk ratio 25.66% and 29.19% above the exact minimum on average, while the corresponding gaps for RBP are 2.64% and 1.77%. The multi-period evaluation uses tracederived workloads whose task realizations are resampled independently and whose moments are known to the scheduler without estimation error. In this setting, RBP lowers the worstserver overload probability by 26.0% and 18.0% relative to the best compared baseline at robust load ratios of 0.90 and 0.95, and keeps the lowest value at every tested load ratio from 0.80 to 0.98 and every tested scale from 5 to 50 servers. An expected-load local search given four times the budget of RBP lowers this probability by less than 3% relative to deterministic greedy. Under the tested conditions, directly optimizing the bottleneck risk ratio achieves a reduction in worst-server overload probability that additional search under an expected-load objective does not reproduce. F UNDING This work was supported by the Inner Mongolia Key Research and Development and Achievement Transformation Program [grant number 2026YFSH0011] and the Inner Mongolia Innovation Capacity Improvement Program [grant number 2026CXHZ0003]. The funders had no role in the study design, the collection, analysis and interpretation of data, the writing of the report or the decision to submit the article for publication. CR EDI T AUTHORSHIP CONTRIBUTION STATEMENT Lei Wang: Conceptualization, Methodology, Software, Validation, Formal analysis, Investigation, Data curation, Writing – original draft, Visualization. Winston K.G. Seah: Supervision, Writing – review & editing. Gang Xu: Resources, Supervision, Project administration, Funding acquisition, Writing – review & editing. Xiaodong Xu: Supervision. Baoqi Huang: Supervision. D ECLARATION OF COMPETING INTEREST The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper. DATA AVAILABILITY The Google cluster-usage traces (ClusterData 2019) used in this study are publicly available [46]. The processed task pool and the preprocessing scripts used to construct it are available on Zenodo [48].

D ECLARATION OF GENERATIVE AI AND AI- ASSISTED TECHNOLOGIES IN THE MANUSCRIPT PREPARATION PROCESS

During the preparation of this work, the authors used ChatGPT (OpenAI) and Claude (Anthropic) in order to improve the language and readability of the manuscript. After using these tools, the authors reviewed and edited the content as needed and take full responsibility for the content of the published article. R EFERENCES [1] W. Shi, J. Cao, Q. Zhang, Y. Li, and L. Xu, “Edge computing: Vision and challenges,” IEEE Internet Things J., vol. 3, no. 5, pp. 637–646, Oct. 2016. [2] P. Mach and Z. Becvar, “Mobile edge computing: A survey on architecture and computation offloading,” IEEE Commun. Surveys Tuts., vol. 19, no. 3, pp. 1628–1656, 2017. [3] Q. Luo, S. Hu, C. Li, G. Li, and W. Shi, “Resource scheduling in edge computing: A survey,” IEEE Commun. Surveys Tuts., vol. 23, no. 4, pp. 2131–2165, 2021. [4] S. Li, C. Li, Y. Huang, B. A. Jalaian, Y. T. Hou, and W. Lou, “Task offloading with uncertain processing cycles,” in Proc. ACM Int. Symp. Mobile Ad Hoc Netw. Comput. (MobiHoc), 2021, pp. 51–60. [5] T. Deng, Z. Yu, and D. Yuan, “Task offloading optimization in mobile edge computing under uncertain processing cycles and intermittent communications,” Comput. Netw., vol. 245, p. 110359, 2024. [6] S. Li, C. Li, Y. Huang, B. A. Jalaian, Y. T. Hou, and W. Lou, “Enhancing resilience in mobile edge computing under processing uncertainty,” IEEE J. Sel. Areas Commun., vol. 41, no. 3, pp. 659–674, Mar. 2023. [7] R. Fan, B. Liang, S. Zuo, H. Hu, H. Jiang, and N. Zhang, “Robust task offloading and resource allocation in mobile edge computing with uncertain distribution of computation burden,” IEEE Trans. Commun., vol. 71, no. 7, pp. 4283–4299, 2023. [8] H. Topcuoglu, S. Hariri, and M.-Y. Wu, “Performance-effective and lowcomplexity task scheduling for heterogeneous computing,” IEEE Trans. Parallel Distrib. Syst., vol. 13, no. 3, pp. 260–274, Mar. 2002. [9] A. Charnes and W. W. Cooper, “Chance-constrained programming,” Manage. Sci., vol. 6, no. 1, pp. 73–79, 1959. [10] A. Nemirovski and A. Shapiro, “Convex approximations of chance constrained programs,” SIAM J. Optim., vol. 17, no. 4, pp. 969–996, 2006. [11] G. C. Calafiore and L. El Ghaoui, “On distributionally robust chanceconstrained linear programs,” J. Optim. Theory Appl., vol. 130, no. 1, pp. 1–22, Jul. 2006. [12] E. Delage and Y. Ye, “Distributionally robust optimization under moment uncertainty with application to data-driven problems,” Oper. Res., vol. 58, no. 3, pp. 595–612, 2010. [13] D. Bertsimas and I. Popescu, “Optimal inequalities in probability theory: A convex optimization approach,” SIAM J. Optim., vol. 15, no. 3, pp. 780–804, 2005. [14] Y. Samadi, M. Zbakh, and C. Tadonki, “E-HEFT: Enhancement heterogeneous earliest finish time algorithm for task scheduling based on load balancing in cloud computing,” in Proc. IEEE Int. Conf. High Perform. Comput. Simul. (HPCS), 2018, pp. 601–609. [15] G. Li, Y. Yao, J. Wu, X. Liu, X. Sheng, and Q. Lin, “A new load balancing strategy by task allocation in edge computing based on intermediary nodes,” EURASIP J. Wirel. Commun. Netw., vol. 2020, p. 3, 2020. [16] H. Dai, X. Zeng, Z. Yu, and T. Wang, “A scheduling algorithm for autonomous driving tasks on mobile edge computing servers,” J. Syst. Archit., vol. 94, pp. 14–23, 2019. [17] X. Deng, J. Li, E. Liu, and H. Zhang, “Task allocation algorithm and optimization model on edge collaboration,” J. Syst. Archit., vol. 110, p. 101778, 2020. [18] L. Huang, S. Bi, and Y.-J. A. Zhang, “Deep reinforcement learning for online computation offloading in wireless powered mobile-edge computing networks,” IEEE Trans. Mobile Comput., vol. 19, no. 11, pp. 2581–2593, 2020. [19] M. Tang and V. W. S. Wong, “Deep reinforcement learning for task offloading in mobile edge computing systems,” IEEE Trans. Mobile Comput., vol. 21, no. 6, pp. 1985–1997, Jun. 2022.

15

[20] H. Djigal, J. Xu, L. Liu, and Y. Zhang, “Machine and deep learning for resource allocation in multi-access edge computing: A survey,” IEEE Commun. Surveys Tuts., vol. 24, no. 4, pp. 2449–2494, 2022. [21] Y. Qu, H. Dai, F. Wu, D. Lu, C. Dong, S. Tang, and G. Chen, “Robust offloading scheduling for mobile edge computing,” IEEE Trans. Mobile Comput., vol. 21, no. 7, pp. 2581–2595, 2022. [22] P. A. Apostolopoulos, G. Fragkos, E. E. Tsiropoulou, and S. Papavassiliou, “Data offloading in UAV-assisted multi-access edge computing systems under resource uncertainty,” IEEE Trans. Mobile Comput., vol. 22, no. 1, pp. 175–190, 2023. [23] H. Zhao, Y. Dong, and J. Wang, “Cluster-and-mapping-based semionline task scheduling for mobile edge computing platforms,” J. Syst. Archit., vol. 177, p. 103847, 2026. [24] Q. Li, S. Wang, A. Zhou, X. Ma, F. Yang, and A. X. Liu, “QoS driven task offloading with statistical guarantee in mobile edge computing,” IEEE Trans. Mobile Comput., vol. 21, no. 1, pp. 278–290, 2022. [25] Y. Chen, B. Ai, Y. Niu, H. Zhang, and Z. Han, “Energy-constrained computation offloading in space-air-ground integrated networks using distributionally robust optimization,” IEEE Trans. Veh. Technol., vol. 70, no. 11, pp. 12 113–12 125, Nov. 2021. [26] R. I. Davis and L. Cucu-Grosjean, “A survey of probabilistic timing analysis techniques for real-time systems,” Leibniz Trans. Embed. Syst., vol. 6, no. 1, pp. 03:1–03:60, 2019. [27] ——, “A survey of probabilistic schedulability analysis techniques for real-time systems,” Leibniz Trans. Embed. Syst., vol. 6, no. 1, pp. 04:1– 04:53, 2019. [28] A. Burns and R. I. Davis, “A survey of research into mixed criticality systems,” ACM Comput. Surv., vol. 50, no. 6, pp. 82:1–82:37, 2018. [29] M. C. Cohen, P. W. Keller, V. Mirrokni, and M. Zadimoghaddam, “Overcommitment in cloud services: Bin packing with chance constraints,” Manage. Sci., vol. 65, no. 7, pp. 3255–3271, 2019. [30] Z. Zhang, B. T. Denton, and X. Xie, “Branch and price for chanceconstrained bin packing,” INFORMS J. Comput., vol. 32, no. 3, pp. 547–564, 2020. [31] Y. Zhang, R. Jiang, and S. Shen, “Ambiguous chance-constrained binary programs under mean-covariance information,” SIAM J. Optim., vol. 28, no. 4, pp. 2922–2944, 2018. [32] J. Yan, Y. Lu, L. Chen, S. Qin, Y. Fang, Q. Lin, T. Moscibroda, S. Rajmohan, and D. Zhang, “Solving the batch stochastic bin packing problem in cloud: A chance-constrained optimization approach,” in Proc. 28th ACM SIGKDD Conf. Knowl. Discov. Data Min. (KDD), 2022, pp. 2169–2179. [33] J. Wu, P. Popov, W. Yang, A. Gudkov, E. Ponomareva, X. Han, Y. Qiu, J. Song, and S. Romanov, “Hotspot-aware scheduling of virtual machines with overcommitment for ultimate utilization in cloud datacenters,” IEEE Trans. Autom. Sci. Eng., vol. 22, pp. 6809–6821, 2025. [34] J. Wu, W. Yang, X. Han, Y. Qiu, A. Gudkov, and J. Song, “Hotspot resolution in cloud computing: A Γ-robust knapsack approach for virtual machine migration,” J. Parallel Distrib. Comput., vol. 186, p. 104817, 2024. [35] Z. Tang, F. Mou, J. Lou, W. Jia, Y. Wu, and W. Zhao, “Joint resource overbooking and container scheduling in edge computing,” IEEE Trans. Mobile Comput., vol. 23, no. 12, pp. 10 903–10 917, 2024. [36] T. Ma, S. Zhang, X. Zhang, Z. Zheng, Z. Wang, and H. Luo, “Following the usage, not the request: Risk-aware task scheduling with overbooking in edge clouds,” in Proc. IEEE Conf. Comput. Commun. (INFOCOM), 2026, pp. 1–10. [37] M. Hähnel, J. Martinovic, G. Scheithauer, A. Fischer, A. Schill, and W. Dargie, “Extending the cutting stock problem for consolidating services with stochastic workloads,” IEEE Trans. Parallel Distrib. Syst., vol. 29, no. 11, pp. 2478–2488, 2018. [38] J. Martinovic, M. Hähnel, G. Scheithauer, and W. Dargie, “An introduction to stochastic bin packing-based server consolidation with conflicts,” TOP, vol. 30, no. 2, pp. 296–331, 2022. [39] T. Wang, S. Homsi, L. Niu, S. Ren, O. Bai, G. Quan, and M. Qiu, “Harmonicity-aware task partitioning for fixed priority scheduling of probabilistic real-time tasks on multi-core platforms,” ACM Trans. Embed. Comput. Syst., vol. 16, no. 4, pp. 101:1–101:21, 2017. [40] J. Ren, Y. Xie, R. Bi, Y. He, G. Wu, and G. Tan, “Workload-aware harmonic partitioned scheduling for fixed-priority probabilistic real-time tasks on multiprocessors,” J. Syst. Archit., vol. 93, pp. 20–32, 2019. [41] J. Kleinberg, Y. Rabani, and É. Tardos, “Allocating bandwidth for bursty connections,” SIAM J. Comput., vol. 30, no. 1, pp. 191–217, 2000. [42] A. Goel and P. Indyk, “Stochastic load balancing and related problems,” in Proc. 40th Annu. Symp. Found. Comput. Sci. (FOCS), 1999, pp. 579– 586. [43] A. Gupta, A. Kumar, V. Nagarajan, and X. Shen, “Stochastic load

balancing on unrelated machines,” Math. Oper. Res., vol. 46, no. 1, pp. 115–133, 2021. [44] G. Song and R. Leus, “Parallel machine scheduling under uncertainty: Models and exact algorithms,” INFORMS J. Comput., vol. 34, no. 6, pp. 3059–3079, 2022. [45] A. Novak, P. Sucha, M. Novotny, R. Stec, and Z. Hanzalek, “Scheduling jobs with normally distributed processing times on parallel machines,” Eur. J. Oper. Res., vol. 297, no. 2, pp. 422–441, 2022. [46] J. Wilkes, “Google ClusterData 2019 (clusterdata-2019) / Google clusterusage traces v3,” https://github.com/google/cluster-data/blob/master/ ClusterData2019.md, 2020, accessed: 2026-01-10. [47] M. Tirmazi, A. Barker, N. Deng, M. E. Haque, Z. G. Qin, S. Hand, M. Harchol-Balter, and J. Wilkes, “Borg: The next generation,” in Proc. 15th European Conf. Comput. Syst. (EuroSys). ACM, 2020, pp. 1–14. [48] L. Wang, “[dataset] processed task pool for “minimizing bottleneck overload risk in online edge task placement under workload uncertainty”,” Zenodo, version v1, https://doi.org/10.5281/zenodo.23074058, 2026.

Related documents

• Sensitivity analysis of the perturbed utility stochastic traffic equilibrium#158640
• Dimensions of perceived algorithmic control and endorsement of minimum-only execution in platform delivery work.#1426600
• Diameter Agent Overload and the Peer Overload Report#502269
• Beyond Scaling: Calculable Error Bounds of the Power-of-Two-Choices Mean-Field Model in Heavy-Traffic#820109
• Systems Optimization#67226