Admin:Scheduling Policies

Criteria
Default scheduling policies should reflect the missions of the clusters being scheduled, and the capabilities of those clusters. Therefore, scheduling priority on a cluster should be based on the following criteria:
 * purpose of the computation, such as undergraduate research, course support, CS and/or another discipline, intent of the computation, etc.;
 * user category, such as CS student, professor or student in another department or at another college;  and
 * job characteristics, including running length of the job, resources required including number of cores, etc.

Utilization of clusters
Both good utilization and good availability of various cluster resources are desirable. When a job qualifies for more than one cluster or job queue, a convenient unified scheduling mechanism should enable that job to run on any available such cluster, subject to the scheduling priority for that cluster. The scheduling algorithm should guarantee that such jobs run only once.

For example, if a job has high priority on a subcluster of MistRider, and a low priority on Helios, it should be possible to schedule that job on Helios if MistRider is continuously busy. However, long jobs should not ordinarily be permitted to run on a subcluster dedicated to short jobs; it may be appropriate to create a new long-job subcluster using some nodes previously dedicated to short jobs, in cases when long-job computations dominate, in order to preserve availability and utilization.

Exceptions
It must be possible to override the default scheduling policies when there is an advantage for the overall cluster project, CS program, or College, as determined by the director of the overall cluster project or his/her designee. For example, near a project deadline in a course that makes intensive use of cluster resources, all available cluster resources may be devoted to course support, including Helios; likewise, at times during a summer, MistRider resources may be dedicated to a lengthy research computation. Scheduling mechanisms should support rapid response to priority changes, for example, if a cluster crashes at the time of a critical computation.