Testbed reservation

 

We’re very happy to announce a highly awaited new feature in CorteXlab: the possibility to reserve the platform. Let me start by giving some history on CorteXlab’s experiment handling, then explain what the reservation subsystem is and what will you gain from it.

History

CorteXlab started off with a very simplistic First In – First Served (FIFS) approach to scheduling user’s tasks (experiments). In this scheme, each task is scheduled as it comes and if there is an experiment running, the new task is put into a queue and waits for its turn. The FIFS approach is acceptable in many situations, except the one where users need to follow the progress of their experiment through our web interface, and do not know in advance when their task will run. The FIFS scheduling is very easy to implement and allowed us to put CorteXlab in operation as fast as possible, but was never meant to be our main scheduling system for very long.

Testbed Reservation

Since a while now we were experimenting with a new scheduling mechanism for CorteXlab based on the OAR system, used in grid computing. As of this week we have ported the OAR system to the production testbed and is now in operation in “beta” mode.

How does it work?

OAR allows for a user to reserve a set of nodes for a certain amount of time on a certain date and time. Furthermore, it checks to see if the nodes are operational (or are under maintenance) and guarantees that only reservations that can be fulfilled be accepted. The reservations can be seen in our Drawgantt web interface, visible here:
Current, future and past reservations are highlighted in a random color and moving the mouse over it, will reveal who reserved it and for what purpose. The number superposed on the job reservation is the Job ID.
At this point it is important to distinguish a “Job” from a “Task”. A Task is an experiment while a Job is a reservation. Since the two notions are disconnected, a user may run one or more experiments (tasks) inside of a reservation period (job). One could interpret a Job as a means to block the testbed to a single user for a time, under which period such user may run as many experiments as he/she wishes. No other user will be able to submit tasks during the reservation of another user.
Some important notes:
  • Reservations are unique, even if other nodes are free. In practical terms, it means that even it is impossible for two users to use the testbed concurrently.
  • Reserving a node does not mean that one is obliged to use it (better be safe than sorry).

How to reserve?

It is quite simple actually. Since no concurrent reservations are possible, one very simple way is to reserve all nodes. This procedure will be detailed in the following. A more detailed manual of the OAR reservation system will be given later in CorteXlab’s wiki page.
Reservations can only be done in the command-line in the airlock server. All the commands that will be shown here must be done in this context. To make a reservation one must do:
$ oarsub -l nodes=BEST,walltime=HH:MM:SS -r "YYYY-MM-JJ HH:MM:SS"
where “walltime” means the reservation duration in hours HH, minutes MM and seconds SS; and the “-r” option stands for the reservation start time at year YYYY, month MM and day DD at hour HH, minute MM and second SS.
After the reservation is validated you should be able to see it in the Drawgantt webpage.
When the reservation time arrives, then one or more tasks can be submitted as specified in Submit experimental tasks in CorteXlab’s wiki.

Other news

During the summer we have updated all nodes to the latest version of GNU Radio, the 3.7.8.