reserve
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
reserve [2016/12/12 11:05] – onicolas | 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:// | ||
+ | * 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" | ||
+ | |||
+ | To book the testbed, you must at least : | ||
+ | * select a start date and hour, | ||
+ | * select a duration OR an end date and hour, | ||
+ | * select " | ||
+ | Then the "Book the testbed" | ||
+ | |||
+ | To go to your reservation list, just click on "My current reservations" | ||
+ | |||
===== Book the testbed with OAR ===== | ===== Book the testbed with OAR ===== | ||
Line 8: | Line 26: | ||
The role of //OAR// is to schedule node reservations. It manages **jobs** associated with users. A job has a start time, a duration (walltime), and uses some resources (CorteXlab nodes). | The role of //OAR// is to schedule node reservations. It manages **jobs** associated with users. A job has a start time, a duration (walltime), and uses some resources (CorteXlab nodes). | ||
+ | |||
+ | ==== Submissions ==== | ||
The principle of operation of CorteXlab is that users submit jobs to OAR. When the job starts, the user gets exclusive access to the platform, and inside an OAR job, the user can perform (interactively, | The principle of operation of CorteXlab is that users submit jobs to OAR. When the job starts, the user gets exclusive access to the platform, and inside an OAR job, the user can perform (interactively, | ||
Line 21: | Line 41: | ||
This command will wait for the resources to be available, and as soon as they are (i.e. -I stands for interactive), | This command will wait for the resources to be available, and as soon as they are (i.e. -I stands for interactive), | ||
- | By default OAR submissions are scheduled as soon as possible. It is also possible | + | Submissions may not be interactive. You can provide a script name to execute when the job starts. It has the strong advantage that it allows you to avoid waiting |
+ | < | ||
- | This other simple example is reserving all the nodes on the 18 of september 2015 from 10h to 11h: | + | A particular case of this syntax is: |
- | < | + | < |
- | This command will wait for the resources | + | It allows you to have a job which is not tied to a terminal, but you still need to manually submit minus tasks when the job starts |
+ | |||
+ | ==== Reservations ==== | ||
By default OAR submissions are scheduled as soon as possible. It is also possible to ask for an OAR // | By default OAR submissions are scheduled as soon as possible. It is also possible to ask for an OAR // | ||
+ | This other simple example is reserving all the nodes on the 18 of September 2015 from 10AM to 11AM: | ||
+ | |||
+ | < | ||
+ | |||
+ | ==== Booking specific nodes ==== | ||
+ | |||
+ | If you want to reserve specific nodes, there are several possible syntaxes. | ||
+ | |||
+ | To make a submission using two nodes: | ||
+ | |||
+ | < | ||
+ | |||
+ | But the nodes will be randomly chosen by OAR, so you'll have to adapt your task's scenario to the allocated nodes. | ||
+ | |||
+ | It is possible to ask for explicit nodes with a less user-friendly syntax (especially in situations where you need lots of nodes). For example, to make a submission using specifically nodes 4 and 6, for a 30 minutes job: | ||
+ | |||
+ | < | ||
+ | |||
+ | Despite this syntax being not user-friendly, | ||
+ | * Nodes are often shutdown, in energy saving mode. Booking only the needed nodes ensures that only these ones will be wakeup. This contributes to increase node lifetime and saving energy | ||
+ | * As only needed nodes are asked, it avoids your oar job being canceled or postponed in case one node that you don't use is unavailable | ||
+ | * It allows tracing more accurately resources usage | ||
+ | |||
+ | ==== Booking the room without any node ==== | ||
+ | |||
+ | You can book the room only, without any node with the following syntax: | ||
+ | |||
+ | < | ||
+ | |||
+ | This is useful in particular if you want to go physically in the room for experimenting with specific hardware, because it avoids waking any node if they are in energy saving mode. | ||
+ | |||
+ | ==== A note on OAR job scheduling ==== | ||
+ | |||
+ | Be aware that OAR behaviour may sometimes be counter-intuitive: | ||
+ | * 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 | ||
+ | * etc. | ||
+ | So, the only reliable way to be sure that your job is actually running is to check that the job's state is "// | ||
+ | |||
+ | < | ||
+ | |||
+ | Tasks submitted to minus will never start unless the job is "// | ||
+ | |||
+ | To sum-up things: | ||
+ | * // | ||
+ | * // | ||
+ | * // | ||
+ | * // | ||
+ | * in the //non interactive// | ||
+ | * in the // | ||
+ | |||
+ | Note that almost all OAR jobs terminate with status "// | ||
+ | ==== A note on energy saving ==== | ||
+ | |||
+ | When nodes are unused, and after a timeout, they will be automatically shutdown (and will appear as "// | ||
+ | |||
+ | When a job is submitted, shutdown nodes are waken up. Thus the job will not start immediately, | ||
+ | |||
+ | When a job is a reservation, | ||
+ | |||
+ | Since energy saving is active, it is strongly encouraged to submit/ | ||
+ | ==== Advanced usage: sharing the platform ==== | ||
+ | |||
+ | It is possible to share the platform, for specific situations such as tutorials, courses, challenges. In these situations, you want several users to be able to use the platform at the same time. For this, you need to follow these steps: | ||
+ | |||
+ | The organizer of the tutorial/ | ||
+ | |||
+ | < | ||
+ | |||
+ | This will reserve all available nodes for a 4 hours event, between 14 and 18 on July 21, 2018. | ||
+ | |||
+ | Then, participants can submit jobs inside the container job with this (example) syntax: | ||
+ | |||
+ | < | ||
+ | |||
+ | or (another example): | ||
+ | |||
+ | < | ||
+ | |||
+ | ==== OAR Documentation ==== | ||
+ | |||
+ | The complete OAR documentation, |
reserve.1481537146.txt.gz · Last modified: 2016/12/12 11:05 by onicolas