JavaScript isn't enabled in your browser, so this file can't be opened. Enable and reload.

1 of 11

2022 CPU Scaling Functions

January 26, 2022

2 of 11

Why scaling

The total demand of RAC applications for CPUs surpasses the total capacity by 100%.
We have no choice but to scale back what’s been asked in order to accommodate researchers’ requests as fairly as possible in a context of shortage of resources.

3 of 11

The rationale: Scaling by scores as a base

The scores quantitatively rank and place applications against one another.
The empirical cumulative distribution function (ECDF - blue) of the scores represents the percentiles of the scores.
We use it as the base for the scaling (green): e.g. if one scored s is above 85% of the rest, then gets 85% of asked A.
The parameters a and b allows us fine tune the scaling,

The parameters a and b are determined by the distribution of the scores.

linear scaling (red)

4 of 11

Scaling 1: Scaling: by score and size of the ask

First, consider

The cumulative sum of asks shows it surpasses the capacity (around 200k core years). We have no choice but cut large asks.
We propose a two variable scaling function by multiplying the ECDF function by a decay function involving the ask A.
The formula below attempts to apply a further discount to the scaled large asks while keeping small asks effectively intact.

The parameters beta and alpha control the shape of the decay function.

Cons:

Scaling by size applies to all, not fair for small ones.

5 of 11

Scaling 2: Compensation for small asks with low scores

Note for low scores, the base scaling function may result in a deep cut, below 20% of the ask.
To accommodate small asks with low scores, we may, if desired, superimpose an artificial “bonus” function (black), exponentially decreasing in both ask and score

The parameter lambda controls the adjustment.

Cons:

The scaling by size might still not be enough to meet the target.

6 of 11

Scaling 3: Applying progressive reduction on scaled asks

Alternatively, consider

For ask A, apply the score-based scaling function (Slide 2 and 3) first to get A’.

Then apply a progressive reduction rate

Using three brackets

7 of 11

Scaling 3: Applying progressive reduction on scaled asks

The rationale

Merit: scaling must be first based on the score.
Capacity: Cuts must be applied to large ones to manage demand.

For 2021, three brackets (CY) are used:

Bracket	% Pop	% Ask	Reduction
0 - 99	31.8%	1.3%	None
100 - 999	51.6%	27%	0.24
1000 and above	16.6%	71.7%	0.38

8 of 11

Scaling 3: Applying progressive reduction on scaled ask

It follows that

Claim 1: For two asks A1 = A2, if the scores s1 < s2, then the awards a1, a2 after the reductions on ask must have a1 < a2.

Claim 2: For two asks A1 < A2, if the scores s1 = s2, then the awards a1, a2 after the reductions on ask must have a1 < a2.

9 of 11

Guard against scaling off

We apply the following

award = max(A_min, scaled value)

where the minimum ask A_mincore year is subject to change in the future.

10 of 11

Scaling in practice

For RAC 2021, the minimum score to receive an allocation is 3.0.
A floor of 50 core years is set for applications with scores of 3.0 or greater.
Successful applications requesting less than 50 core years but more than 50 core equivalent receive 100% of the CPU requested.

Overall score	Scaling factor	CPU Ask (core years)	CPU Allocation (core years)
4.9	0.65	4,320	2792
4.8	0.90	175	157
4.8	0.86	230	199
4.7	0.91	161	146
4.7	1.00	47	47
4.7	1.00	60	60
4.0	0.48	2,700	1300
4.0	0.70	225	158
3.7	0.38	1,900	724
3.7	0.48	428	204
3.1	0.18	1,050	187
3.1	1.00	53	53
3.1	0.36	321	116
3.0	0.12	1,900	230
3.0	0.37	309	115

11 of 11

Scaling functions

See the full notes on scaling functions for details

https://drive.google.com/file/d/1qD-wfq_oZ7grzGZP6N60FMxH4vOSwzSr/view?usp=sharing