Reservations - Revision history

Haars0011 at 13:54, 6 February 2025

2025-02-06T13:54:20Z

← Older revision		Revision as of 15:54, 6 February 2025
Line 16:		Line 16:

	== Costs ==		== Costs ==
	The costs will be 30 euro per node per day + the additional costs of the job itself.		The costs will be 50 euro per node per day + the additional costs of the job itself.

Haars0011 at 13:19, 28 January 2025

2025-01-28T13:19:06Z

← Older revision		Revision as of 15:19, 28 January 2025
Line 16:		Line 16:

	== Costs ==		== Costs ==
	The costs will be 50 euro per node per day + the additional costs of the job itself.		The costs will be 30 euro per node per day + the additional costs of the job itself.

Lith010: /* Cost */

2017-08-25T12:52:05Z

Cost

← Older revision		Revision as of 14:52, 25 August 2017
Line 15:		Line 15:
	In addition, it's not currently possible to reserve less than entire nodes at a time, as there's no means to reserve memory and cores separately (And there'd be no guarantee that they'd be on the same machine if so). Thus, the minimum reservation possible is one normal node, and the maximum should be no more than three in order to not disrupt the main workflow.		In addition, it's not currently possible to reserve less than entire nodes at a time, as there's no means to reserve memory and cores separately (And there'd be no guarantee that they'd be on the same machine if so). Thus, the minimum reservation possible is one normal node, and the maximum should be no more than three in order to not disrupt the main workflow.

	== ~~Cost~~ ==		== Costs ==
	The ~~cost~~ will be 50 euro per node per day + the additional costs of the job itself.		The costs will be 50 euro per node per day + the additional costs of the job itself.

Lith010 at 12:51, 25 August 2017

2017-08-25T12:51:54Z

← Older revision		Revision as of 14:51, 25 August 2017
Line 14:		Line 14:

	In addition, it's not currently possible to reserve less than entire nodes at a time, as there's no means to reserve memory and cores separately (And there'd be no guarantee that they'd be on the same machine if so). Thus, the minimum reservation possible is one normal node, and the maximum should be no more than three in order to not disrupt the main workflow.		In addition, it's not currently possible to reserve less than entire nodes at a time, as there's no means to reserve memory and cores separately (And there'd be no guarantee that they'd be on the same machine if so). Thus, the minimum reservation possible is one normal node, and the maximum should be no more than three in order to not disrupt the main workflow.

			== Cost ==
			The cost will be 50 euro per node per day + the additional costs of the job itself.

Dawes001 at 11:13, 9 June 2017

2017-06-09T11:13:51Z

← Older revision		Revision as of 13:13, 9 June 2017
Line 6:		Line 6:
	In order to use a reservation, simply add the following line into your sbatch script:		In order to use a reservation, simply add the following line into your sbatch script:
	<nowiki>#SBATCH --reservation="MyReservation"</nowiki>		<nowiki>#SBATCH --reservation="MyReservation"</nowiki>
	When you submit your job, SLURM is then asked if you can use these resources. If yes, then your job will proceed as soon as there are resources available inside the reserved allocation.		Replacing 'MyReservation' with the name of the reservation you wish to use. To see current reservations:
			<nowiki>scontrol show reservations</nowiki>
			The currently valid reservations are marked as State=ACTIVE; When you submit your job using a reservation definition, SLURM is then asked if you can use these resources. If yes, then your job will proceed as soon as there are resources available inside the reserved allocation. If no, then your job will fail to submit.

	== Requesting a Reservation ==		== Requesting a Reservation ==

Dawes001 at 11:07, 9 June 2017

2017-06-09T11:07:34Z

← Older revision		Revision as of 13:07, 9 June 2017
Line 1:		Line 1:
	SLURM is capable of assuring resources be available at a specified time for a specified set of users ~~and/or groups~~ via the use of reservations. A reservation can be made far in advance of the time when the resources are needed, and SLURM will automatically prevent jobs from being scheduled that do not belong to that reservation during that time. In fact, the earlier the better - this allows long jobs to terminate properly.		SLURM is capable of assuring resources be available at a specified time for a specified set of users via the use of reservations. A reservation can be made far in advance of the time when the resources are needed, and SLURM will automatically prevent jobs from being scheduled that do not belong to that reservation during that time. In fact, the earlier the better - this allows long jobs to terminate properly.

	This may be required in extreme circumstances where resources must be available for demonstration or teaching purposes at the moment when the event is happening.		This may be required in extreme circumstances where resources must be available for demonstration or teaching purposes at the moment when the event is happening.
Line 9:		Line 9:

	== Requesting a Reservation ==		== Requesting a Reservation ==
	There is no way to create a reservation yourself - an admin must create it. To request a reservation, please email your system administrator. Given that this will dedicate the resources away from general use, there will be a financial cost involved in this, typically equivalent to the cost of running jobs for the entire period defined.		There is no way to create a reservation yourself - an admin must create it. To request a reservation, please email your system administrator and define the list of users (not groups!) who may use this reservation. Given that this will dedicate the resources away from general use, there will be a financial cost involved in this, typically equivalent to the cost of running jobs for the entire period defined.

	In addition, it's not currently possible to reserve less than entire nodes at a time, as there's no means to reserve memory and cores separately (And there'd be no guarantee that they'd be on the same machine if so). Thus, the minimum reservation possible is one normal node, and the maximum should be no more than three in order to not disrupt the main workflow.		In addition, it's not currently possible to reserve less than entire nodes at a time, as there's no means to reserve memory and cores separately (And there'd be no guarantee that they'd be on the same machine if so). Thus, the minimum reservation possible is one normal node, and the maximum should be no more than three in order to not disrupt the main workflow.

Dawes001: Created page with "SLURM is capable of assuring resources be available at a specified time for a specified set of users and/or groups via the use of reservations. A reservation can be made far i..."

2017-06-09T11:05:16Z

Created page with "SLURM is capable of assuring resources be available at a specified time for a specified set of users and/or groups via the use of reservations. A reservation can be made far i..."

New page

SLURM is capable of assuring resources be available at a specified time for a specified set of users and/or groups via the use of reservations. A reservation can be made far in advance of the time when the resources are needed, and SLURM will automatically prevent jobs from being scheduled that do not belong to that reservation during that time. In fact, the earlier the better - this allows long jobs to terminate properly.

This may be required in extreme circumstances where resources must be available for demonstration or teaching purposes at the moment when the event is happening.

== Usage ==
In order to use a reservation, simply add the following line into your sbatch script:
<nowiki>#SBATCH --reservation="MyReservation"</nowiki>
When you submit your job, SLURM is then asked if you can use these resources. If yes, then your job will proceed as soon as there are resources available inside the reserved allocation.

== Requesting a Reservation ==
There is no way to create a reservation yourself - an admin must create it. To request a reservation, please email your system administrator. Given that this will dedicate the resources away from general use, there will be a financial cost involved in this, typically equivalent to the cost of running jobs for the entire period defined.

In addition, it's not currently possible to reserve less than entire nodes at a time, as there's no means to reserve memory and cores separately (And there'd be no guarantee that they'd be on the same machine if so). Thus, the minimum reservation possible is one normal node, and the maximum should be no more than three in order to not disrupt the main workflow.