SIGN-IN

Scheduling Policy

The following information is an outline of the manner in which scheduling decisons are made on SHARCNET systems. The details are expected to change as the scheduling process is refined.

SHARCNET currently uses Platform's LSF scheduler with some local additions. LSF uses the concept of user "shares" to allocate system resources to user jobs so as to provide fair access in a shared environment.

Many factors affect the scheduling of an individual job (queue priority, resources requested, etc) but, all other factors being equal, a job submitted by a user with a larger number of shares will be run before the job of a user with a lower number of shares. The number of shares - or the priority - that a user has at any any given time is based on several factors such as: the initial number of shares; current resources in use; the total amount of resources used recently, etc.

  • At present all users have an equal initial allocation of shares.
  • SHARCNET calculates the number of shares, and hence the priority of starting a queued job, according to usage across all of SHARCNET. Thus significant recent usage on one system will affect the probability of starting a job on another.
  • Shares, and therefore job priorities, are computed on a group-wise basis. Thus, the onus is on group PIs to ensure that group members are making effective use of their group's use of SHARCNET.
  • A group's job priority is calculated twice a day from data accumulated from use on all SHARCNET systems and assigned to one of six categories: default priority 5 (high) to lowest priority, level 0.
  • To calculate which priority level a group is set to after each twice daily reset, the total cpu usage is summed for all user jobs in a group over the past two months. Goups are then ordered by usage and divided evenly among priority levels 0-5, lightest into group 5 and heaviest into group 0.
  • Non-Canadian accounts are automatically assigned to priority level 0.
  • Normal use is presently "charged" per cpu-hour (with totals of less than one cpu-hour in the twice-daily calculation being ignored).
  • Use of the test queue is charged at four times the normal rate.
  • Older clusters with slower processors will be charged at a lower per cpu-hour rate.
  • Users who have received dedicated time use these allocations outside the regular scheduling framework described above and such use does not affect priority of other jobs.
  • Some clusters may be configured to employ experimental scheduling, for further details please see this link.