Differences

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

--- abstract:farber:runjobs:queues [2018-05-24 11:06] – sraskar
+++ abstract:farber:runjobs:queues [2018-10-08 16:00] – anita
@@ Line 1: / Line 1: @@
-===== The job queues on Farber =====
+====== The job queues on Farber ======
 Each investing-entity on a cluster an //owner queue// that exclusively use the investing-entity's compute nodes. (They do not use any nodes belonging to others.) Grid Engine allows those queues to be selected only by members of the investing-entity's group.
@@ Line 27: / Line 27: @@
 In addition to the required run-time limit, the standby queues differ by how many jobs each user can be concurrently running.  More jobs can be run in the standby queues requiring shorter time limits.
 </note>
 ===== Farber "standby" queues =====
@@ Line 49: / Line 42: @@
 </code>
-====Grid Engine resources governing these queues====
+==== Grid Engine resources governing these queues ====
 The "standby" queues are assigned based on the number of slots and the maximum (wall-clock) //hard// run-time you specify. Typically each cluster defines a default //hard// run-time limit as well as a maximum number of slots allowed per user for standby jobs.
@@ Line 118: / Line 111: @@
 </note>
+===== Farber Exclusive access =====
-====== Farber Exclusive access ======
 If a job is submitted with the ''-l exclusive=1'' resource, Grid Engine will
@@ Line 158: / Line 149: @@
 qsub -l exclusive=1 ...
 </code>
@@ Line 191: / Line 181: @@
+==== Actions at the run-time limit =====
-=====Actions at the run-time limit=====
 When a standby job reaches its maximum run time, Grid Engine kills the job. The process depends on your use of Grid Engine's ''-notify'' flag and how your job handles the resulting ''USR2'' notification signal.