Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify and document rounding for resource allocation list #3584

Open
yuvipanda opened this issue Jan 6, 2024 · 1 comment
Open

Clarify and document rounding for resource allocation list #3584

yuvipanda opened this issue Jan 6, 2024 · 1 comment
Labels
Documentation A change to our documentation.

Comments

@yuvipanda
Copy link
Member

The list of resource allocations that end users can choose from on the VEDA hub looks like this:

image

Why are these numbers odd?

The reason these are a bit odd (1.9GB instead of 2GB, etc) is so we account for overhead of running various system and support components on each node, so not all the resources of the node are available for end users to use. The resources that are available, we split into chunks that fit together proportionally to minimize the amount of possible wasted space. #3030 is the PR that originally added this, and has a lot of rationale in the description about how they are calculated.

Why do we show these numbers?

Why do we show these odd numbers? It's because if I log in, and in the bottom of JupyterLab, I see the current memory limit:

image

When an end user hits this memory limit, they start seeing their kernels die. Kernels dying due to memory exhaustion is perhaps the number one confusing thing that end users experience on a JupyterHub that they don't on their local machine. If you exhaust memory on your local machine, everything freezes. Here, the kernel dies.

So when building the script to generate these choices (#3030), I made the display of memory match the actual memory limit, so it is easy for the user to understand where this number was coming from. It does mean that the numbers look 'odd', but I personally think it's better to have one number be in the server startup screen and in jupyterlab and that look odd, than to have two different numbers here simply so that they look more rounded out.

However, everyone always asks why this number looks odd, so we should at least document this someplace nice.

@yuvipanda
Copy link
Member Author

yuvipanda commented Jan 6, 2024

For CPU though, I think we don't need to show 2 decimals after the ., 1 is probably fine. I opened #3585 to address that.

yuvipanda added a commit to yuvipanda/pilot-hubs that referenced this issue Jan 6, 2024
Brings it down to one digit after decimal, rather than 2.

Ref 2i2c-org#3584
@GeorgianaElena GeorgianaElena added the Documentation A change to our documentation. label Jan 17, 2024
@damianavila damianavila moved this from Needs Shaping / Refinement to In progress in DEPRECATED Engineering and Product Backlog Jan 18, 2024
@damianavila damianavila moved this to In Progress ⚡ in Sprint Board Jan 18, 2024
@yuvipanda yuvipanda removed their assignment Jan 25, 2024
@damianavila damianavila assigned yuvipanda and unassigned yuvipanda Jan 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation A change to our documentation.
Projects
No open projects
Status: In Progress
Development

No branches or pull requests

2 participants