You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit b3170ad
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: POLICY.md
+12-12Lines changed: 12 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,11 +1,11 @@
1
1
# Policy
2
2
3
-
## Organization
3
+
## Organisation
4
4
5
5
### Teams, projects and budgets
6
-
The principles is that faircenter helps organize work into teams and projects (optionally), and maps resources to the people, teams and projects. People can belong to one or multiple teams, and work on one or multiple projects.
6
+
The principle is that faircenter helps organise work into teams and projects (optionally), and maps resources to the people, teams and projects. People can belong to one or multiple teams, and work on one or multiple projects.
7
7
8
-
The cluster's GPU time is divided into two pools: a persons pool and teams pool. The person pool allows individuals to do exploratory work and does not draws a team's budget. A project draws only on the pool that funds it. A teams pool might be divided across its projects, or kept as a single pool. A team budget renews and a project budget is dated. A team's pool is a recurring allowance that resets each period, so a team plans against a steady share. It can ask for augmentation when that share runs too small. A project's budget has a deadline, which can be extended when the work needs longer.
8
+
The cluster's GPU time is divided into two pools: a person pool and a teams pool. The person pool allows individuals to do exploratory work and does not draw a team's budget. A project draws from its team pool. A team pool might be divided across its projects, or kept as a single pool. A team budget renews and a project budget is dated. A team's pool is a recurring allowance that resets each period, so a team plans against a steady share. It can ask for augmentation when that share runs too small. A project's budget has a deadline, which can be extended when the work needs longer.
9
9
10
10
```mermaid
11
11
graph TD
@@ -27,7 +27,7 @@ graph TD
27
27
Roles are allocated to people, and these can be temporary, or long term. Roles determine which requests can be made or approved, and which policy values can be set. E.g., a team leader can distribute their team budget pool across projects, while operations can distribute the total capacity between teams (and persons). Team leadership can be held, shared, left empty, or reassigned. If empty, decisions are deferred to operations.
28
28
29
29
### Priorities
30
-
Resource allocation is managed in two ways: budget and priority (standing). The proposed policy is that personal budgets are of the lowest priority. They have no guareteed capacity, but can use a certain budget over time. Team budgets similarly have a set pool, but come with the ability to commit a job in a low, medium or high priority lane. Prioritiy comes with a cost of burning through more budget. Team jobs always have priority over personal jobs. If the team leader decides to do so, they can enable project budgets within their team, allowing them to distribute their total budget across the projects, ensuring sufficient resources for certain higher priority projects. Finally, teams can be ranged in priority, determined by management, and implemented by operations.
30
+
Resource allocation is managed in two ways: budget and priority (standing). The proposed policy is that personal budgets are of the lowest priority. They have no guaranteed capacity, but can use a certain budget over time. Team budgets similarly have a set pool, but come with the ability to commit a job in a low, medium or high priority lane. Priority comes with a cost of burning through more budget. Team jobs always have priority over personal jobs. If the team leader decides to do so, they can enable project budgets within their team, allowing them to distribute their total budget across the projects, ensuring sufficient resources for certain higher priority projects. Finally, teams can be ranked in priority, determined by management, and implemented by operations.
31
31
32
32
33
33
```mermaid
@@ -42,7 +42,7 @@ graph TD
42
42
```
43
43
44
44
### Allocation and reservations
45
-
fairsharing provides a tab to request new projects, or changes in budget or priority, which are forwarded for approval. GPUs can also be reserved. However this blocks them for any other('s) use, so is planned with the help of a view on load and planned capacity.
45
+
faircenter provides a tab to request new projects, or changes in budget or priority, which are forwarded for approval. GPUs can also be reserved. However this blocks them for any other('s) use, so is planned with the help of a view on load and planned capacity.
46
46
47
47
48
48
```mermaid
@@ -59,13 +59,13 @@ graph TD
59
59
A GPU is one accelerator, a headcount. A GPU-hour is one GPU running for one hour: a volume of work. The two convert through time, GPU-hours = GPUs × hours. Pools, team allowances and capacity are shares of the cluster, so the app shows them as GPUs: a team allowance of two hundred GPUs holds that many of the cluster's GPUs on average, and the person and team pools add up to the cluster's headcount. A project budget is different, an amount of compute a dated piece of work may spend, so it is GPU-hours over that project's own start-to-end. Utilisation is GPU-hours used over GPU-hours offered across a window, the same ratio as average GPUs in use over GPUs installed, so it carries no unit.
60
60
61
61
## Mechanisms
62
-
The policy is implemented in a small set of transparent mechanisms that determine how the limited GPU resources can be used. As described in the [strategy](STRATEGY.md), a gradually "switching on" of these mechanisms, and their fine-tuning, will align GPU usage fairly, and according to the organizational priorities.
62
+
The policy is implemented in a small set of transparent mechanisms that determine how the limited GPU resources can be used. As described in the [strategy](STRATEGY.md), a gradual "switching on" of these mechanisms, and their fine-tuning, will align GPU usage fairly, and according to the organisational priorities.
63
63
64
-
- Person budgets: cap each person at their budget
65
-
- Team budgets:cap each team pool
66
-
- Project budgets:cap each project at its budget
67
-
- Priced urgency (lanes): fast and bulk lanes available to jobs
68
-
- Time-of-use weighting: office/off-hours weight on budget drawn
64
+
- Person budgets: cap each person at their budget
65
+
- Team budgets:cap each team pool
66
+
- Project budgets:cap each project at its budget
67
+
- Priced urgency (lanes): fast and bulk lanes available to jobs
68
+
- Time-of-use weighting: office/off-hours weight on budget drawn
Copy file name to clipboardExpand all lines: README.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,7 +15,7 @@ graph BT
15
15
```
16
16
17
17
## Fit within the existing ecosystem
18
-
faircenter aims to interface with existing tools. E.g., People and projects are imported from Notion, SLURM implements scheduling and standing, and communication and done via slack. Identity is assumed to come from single sign-on.
18
+
faircenter aims to interface with existing tools. E.g., People and projects are imported from Notion, SLURM implements scheduling and standing, and communication is done via slack. Identity is assumed to come from single sign-on.
19
19
20
20
```mermaid
21
21
graph TD
@@ -39,7 +39,7 @@ graph TD
39
39
```
40
40
41
41
## Documentation
42
-
The [manual](MANUAL.md) walks through the app tab by tab. The [policy](POLICY.md) sets out the policies and parameters values, introducing a distribution of GPU "budget" across persons, teams and projects. [strategy](STRATEGY.md) explained how the policy could be phased in over time, anticipating a gradual organization twards team and project-oriented budgets, while minimizing administrative burden and maximizing both transparancy and decision-making at each level, and inclkudes a discussion of risks.
42
+
The [manual](MANUAL.md) walks through the app tab by tab. The [policy](POLICY.md) sets out the policies and parameters values, introducing a distribution of GPU "budget" across persons, teams and projects. [strategy](STRATEGY.md) explained how the policy could be phased over time, anticipating a gradual organization towards team and project-oriented budgets, minimizing administrative burden and maximizing transparancy and decision-making at each level.
0 commit comments