Differences

This shows you the differences between two versions of the page.

--- reserve [2022/09/09 08:02] – [A note on OAR job scheduling] mimbert
+++ reserve [2022/11/18 16:43] (current) – pgirard
@@ Line 1: / Line 1: @@
+===== Book the testbed with the Cortexlab web application =====
+**Booking the Cortexlab platform with the Cortexlab web application saves you from using the OAR commands like described in the "Book the testbed with OAR" section below.**
+When logged in (https://xp.cortexlab.fr/app), you can see :
+  * the planning (Drawgantt),
+  * your reservation list (of course you can delete a reservation),
+  * the button to book the testbed.
+You can also make your reservation(s) by clicking on the "Book the testbed" sub-menu in the navigation bar "Reservation" menu.
+To book the testbed, you must at least :
+  * select a start date and hour,
+  * select a duration OR an end date and hour,
+  * select "Reservation room" checkbox OR one or more nodes.
+Then the "Book the testbed" button will be activated, to request your reservation.
+To go to your reservation list, just click on "My current reservations" sub-menu in the navigation bar "Reservation" menu.
 ===== Book the testbed with OAR =====
@@ Line 83: / Line 101: @@
 To sum-up things:
   * //Submissions// versus //Reservations//:
-    * //Submission//: To get the resources as soon as possible. You do not control when the job will be scheduled, and as long as the job hasn't started, the schedule may change. You may get the resources right now if OAR can (and decides to) schedule the job immediately, but there's no guarantee. With a //Submission// you are __sure to get the resources you asked, but you don't control when__ (the extreme case is that if a resource becomes permanently unavailable, like for example when a node is broken, then your job will never be scheduled, ie. it will stay in "Waiting" state indefinitely)
+    * //Submission//: To get the resources as soon as possible. You do not control when the job will be scheduled, and as long as the job hasn't started, the schedule may change. You may get the resources right now if OAR can (and decides to) schedule the job immediately, but there's no guarantee. __With a //Submission// you are sure to get the resources you asked, but you don't control when__ (the extreme case is that if a resource becomes permanently unavailable, like for example when a node is broken, then your job will never be scheduled, ie. it will stay in "//Waiting//" state indefinitely)
-    * //Reservation//; you ask for resources at a specific date. __You are sure to get your job at the date you requested__ (with sometimes a few minutes margin), __but you are not sure to get exactly the resources__ (some resources may have become unavailable at that date)
+    * //Reservation//; you ask for resources at a specific date. __With a //Reservation// you are sure to get the resources at the date you requested (with sometimes a few minutes margin), but you are not sure to get exactly the resources you requested__ (some resources may have become unavailable at that date)
   * //Interactive// versus //Non Interactive//:
     * in the //non interactive// case, you provide an executable which will be executed by OAR on airlock during your job. This executable can be anything, a ''sleep infinity'' command, a script, a binary executable. It will be run at job start and killed at job end. If it ends before the walltime of the job, the job terminates. You can for example provide a script that runs one or several ''minus task submit'' commands to fully automate an experimental campaign (but beware that your script needs to wait for the end of the last minus task execution, otherwise, the job will be killed (together with the last minus task) when the script terminates.
@@ Line 92: / Line 110: @@
 ==== A note on energy saving ====
-When nodes are unused, and after a timeout, they will be automatically shutdown (and will appear as "standby" in the drawgantt)
+When nodes are unused, and after a timeout, they will be automatically shutdown (and will appear as "//Standby//" in the drawgantt)
-When a job is submitted, shutdown nodes are waken up. Thus the job will not start immediately, it will wait for the nodes to have started. If some nodes are not started after the timeout, the job will start without these nodes (and the nodes will be set in state "absent")
+When a job is submitted, shutdown nodes are waken up. Thus the job will not start immediately, it will wait for the nodes to have started. If some nodes are not started after the timeout, they will be set in state "//Absent//". If the job is a reservation, it will start without these nodes. If it is a submission, it will scheduled later (possibly never, OAR will wait for the resource to be back, which may never happen)
-When there is a reservation, oar knows the scheduled start and starts to wakeup nodes before the scheduled start of the job, so usually the job should start as planned.
+When a job is a reservation, OAR knows the scheduled start and starts to wakeup nodes before the scheduled start of the job, so usually the job should start approximately as planned.
+Since energy saving is active, it is strongly encouraged to submit/reserve only the nodes you need, and if you don't need any node, to only submit/reserve the //room//. It will save energy, avoid heating the room needlessly, increase longevity of our hardware. Also nodes are awaken by groups of 5, so the more nodes you reserve, the longer the startup time of your job, maybe up to 15 minutes if you reserve all nodes.
 ==== Advanced usage: sharing the platform ====