2.8 Priorities in Condor

Condor has two independent priority controls: job priorities and user priorities.

2.8.1 Job Priority

Job priorities allow you to assign a priority level to each of your jobs in order to control their order of execution. To do this, use the condor_prio command -- see the example in section 2.7.4, or the command reference page on page . Job priorities, however, do not impact user priorities in any fasion. No matter what you set a job's priority to be, it will not alter your user priority in relation to other users. Job priorities range from -20 to +20, with +20 being the best and -20 the worst.

  
2.8.2 User priority

Machines are allocated to users based upon that user's priority. User priorities in Condor can be examined with the condor_userprio command (see page ), and Condor administrators can set and edit individual user priorities with the same utility. A lower numerical user priority value means higher priority, so a user with priority 5 will get more resources than a user with priority 50.

Condor continuously calculates the share of available machines that each user should be allocated. This share is inversely related to the ratio between user priorities; for example, a user with a priority of 10 will get twice as many machines as a user with a priority of 20. The priority of each individual user changes according to the number of resources he is using. Each user starts out with a priority of .5 (the best priority allowed). If the number of machines a user currently has is greater than his priority, the priority will numerically increase (worsen) over time, and if it is less then the priority, the priority will numerically decrease (improve) over time. The long-term result is fair-share access across all users. The speed at which Condor adjusts the priorities is controlled via an exponential half-life value (parameter PRIORITY_HALFLIFE which can be adjusted by the site administrator) which has a default of one day. So if a user with a user priority of 100 is utilizing 100 machines and then deletes all his/her jobs, one day later that user's priority will 50, two days later the priority will be 25, etc.

Condor enforces that each user gets his/her fair share of machines according to user priority both when allocating machines which become available and by priority preemption of currently allocated machines. For instance, if a low priority user is utilizing all available machines and suddenly a higher priority user submits jobs, Condor will imediately checkpoint and vacate jobs belonging to the lower priority user. This will free up machines that Condor will then give over to the higher priority user. Condor will not starve the lower priority user; it will preempt only enough jobs so that the higher priority user's fair share can be realized (based upon the ratio between user priorities). To prevent thrashing of the system due to priority preemption, the Condor site administrator can define a PREEMPTION_HOLD expression in Condor's configuration. The default expression that ships with Condor is configured to only preempt lower priority jobs that have run for at least one hour. So in the previous example, in the worse case it could take up to a maximum of one hour until the higher priority user receives his fair share of machines.

User priorities are keyed on ``username@domain'', for example ``johndoe@cs.wisc.edu''. (The domainname to use, if any, is also configured by the Condor site administrator). Thus, user priority and therefore resource allocation is not impacted by which machine the user submits from or even if the user submits jobs from multiple machines.

Finally, any job submitted to Condor can be specified as a ``nice'' job at the time the job is submitted (see page ). Nice jobs will artificially have their numerical priority boosted by over one million. This effectively means that nice jobs will only run on machines that no other Condor job (i.e. non-niced job) wants. Similarly, the Condor administrators could set the numerical priority of any individual Condor user, such as a guest account, so that these guest accounts would only use cycles not wanted by other users of the system.