Express queue for testing job scripts and interactive jobs.

The express queue

By submitting a job to the express queue you can get higher throughput for testing and shorter start up time for interactive jobs. Just use the -q express flag to submit to this queue:

qsub -q express jobscript.sh

or for an interactive job:

qsub -q express -I

This will give you a faster access if you have special needs during development, testing of job script logic or interactive use.

Priority and limitations

Jobs in the express queue will get higher priority than any other jobs in the system and will thus have a shorter queue delay than regular jobs. To prevent misuse the express queue has the following limitations:

• Only one running job per user.
• Maximum 8 hours walltime.
• Maximum 8 nodes per job. This allows for jobs requesting up to 64 cpus to run in the queue, -lnodes=8:ppn=8. Remark: -lnodes=64 will NOT work, the nodes number must be less than or equal 8.
• Only one job queued at any time, remark this is for the whole queue. This is to prevent express jobs delaying large regular jobs.

So, it is more or less pointless to try to use the express queue to sneak regular production jobs passed the other regular jobs. Submitting a large amount of jobs to the express queue will most probably decrease the overall throughput of your jobs. Also remark that large jobs get prioritized anyway so they will most probably not benefit anything from using the express queue.

Extremely short jobs

One compute node is reserved for running jobs with a walltime less than 15 minutes. It is not necessary to use the express queue for accessing this node. Rather, it is not even recommended to use the express queue for this, as it might delay the jobs due to the limitations listed above.