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
Alternatively/additionally to a fixed upper boundary on the number of resources (current quota parameter), it would be good to have a mechanism that pursues a longterm average, e.g. implemented as a dynamically acting limiter in addition to the quota that defines the (higher) absolute limit of resources.
If there is a certain amount of compute time granted on a cluster, one might try to constantly run the corresponding amount of resources. But if less resources are run (e.g. if too many other users in the queue or too little load on the OBS), one would like to book more resources at a later point in time in order to catch up and finally use up the granted compute time.
A dynamic limiter based on accounting data could automatize this. A choice of different logics/agility levels might be useful.
The text was updated successfully, but these errors were encountered:
@swozniewski thanks a lot for submitting the issue. As already discussed I think that is a feature that needs to be supported for upcoming NHR integration.
Alternatively/additionally to a fixed upper boundary on the number of resources (current quota parameter), it would be good to have a mechanism that pursues a longterm average, e.g. implemented as a dynamically acting limiter in addition to the quota that defines the (higher) absolute limit of resources.
If there is a certain amount of compute time granted on a cluster, one might try to constantly run the corresponding amount of resources. But if less resources are run (e.g. if too many other users in the queue or too little load on the OBS), one would like to book more resources at a later point in time in order to catch up and finally use up the granted compute time.
A dynamic limiter based on accounting data could automatize this. A choice of different logics/agility levels might be useful.
The text was updated successfully, but these errors were encountered: