User Tools

Site Tools


reserve

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
reserve [2022/09/09 08:24] – [A note on OAR job scheduling] mimbertreserve [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 ===== ===== Book the testbed with OAR =====
  
Line 83: Line 101:
 To sum-up things: To sum-up things:
   * //Submissions// versus //Reservations//:   * //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. __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)     * //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//:   * //Interactive// versus //Non Interactive//:
Line 96: Line 114:
 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 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 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 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, up to 15 minutes if you reserve all nodes.+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 ==== ==== Advanced usage: sharing the platform ====
  
reserve.1662704641.txt.gz · Last modified: 2022/09/09 08:24 by mimbert

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki