Differences

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

--- reserve [2022/08/30 10:39] – 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 70: / Line 88: @@
 ==== A note on OAR job scheduling ====
-Be aware that OAR behaviour may sometimes be counter-intuitive: You may think that just because you ran oarsub successfuly and it returns a job id, your job is running, but this assumption is wrong: OAR tells you that it accepts your job submission but it may schedule it later for various reasons:
+Be aware that OAR behaviour may sometimes be counter-intuitive: You may think that just because you ran ''oarsub'' successfuly and it returns a job id, your job is running, but this assumption is wrong: OAR tells you that it accepts your job submission but it may schedule it later for various reasons:
   * because the nodes are currently shutdown, so it needs to wake them up, which may take some time
   * because another job is running
-  * because the resources you ask are currently not available but oar expects them to be available in the future
+  * because the resources you ask are currently not available but OAR expects them to be available in the future
   * etc.
-So, the only reliable way to be sure that your job is actually running is to check that the job's state is "Running" with command:
+So, the only reliable way to be sure that your job is actually running is to check that the job's state is "//Running//" with command:
 <code>oarstat -fj <JOBID></code>
-Tasks submitted to minus will never start unless the job is "Running" anyway.
+Tasks submitted to minus will never start unless the job is "//Running//" anyway.
+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)
+    * //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.
+    * in the //interactive// case, the executable is actually an interactive subshell started by OAR on airlock. Beware, if this subshell terminates, the job will be killed as well (you can prevent that by running interactive submissions inside a [[https://www.gnu.org/software/screen/|gnu screen]] or [[https://github.com/tmux/tmux/wiki|tmux]] to protect from ssh disconnections. Both are installed on airlock. For this, you need to open the ssh connection to airlock, then start a gnu screen / tmux session, then run your interactive jobs in that session. The gnu screen / tmux session will survice ssh disconnections or shutdowns of your workstation, and can be rejoined later)
+Note that almost all OAR jobs terminate with status "//Error//". It's actually a side effect of the fact that the status of a terminated OAR job depends on the return code of the job executable. If it returns 0 (the unix convention for success, or True) the job is in "//Terminated//" state, if it returns anything but 0 (the unix convention for failure, or False), the job is in "//Error//" state. Most jobs use ''sleep infinity'' as executable, and ''sleep'' returns something different than 0 when it is killed at job end.
 ==== 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 ====