{section: How to configure priorities/quotas for groups of users}
-Known to work with Condor version: 7.0
+Known to work with HTCondor version: 7.0
-By default, Condor provides fair sharing between individual users by keeping track of usage and adjusting their relative user priorities in the pool. Frequently, however, there is a need to allocate resources at a higher level. Suppose you have a single Condor pool shared by several groups of users. Your goal is to configure Condor so that each group gets its fair share of the computing resources and within each group, each user gets a fair share relative to other members of the group. What is "fair" depends on circumstances, such as whether some groups own a larger share of the machines than others and whether some groups have a different pattern of usage such as occasional bursts of computation verses steady demand.
+By default, HTCondor provides fair sharing between individual users by keeping track of usage and adjusting their relative user priorities in the pool. Frequently, however, there is a need to allocate resources at a higher level. Suppose you have a single HTCondor pool shared by several groups of users. Your goal is to configure HTCondor so that each group gets its fair share of the computing resources and within each group, each user gets a fair share relative to other members of the group. What is "fair" depends on circumstances, such as whether some groups own a larger share of the machines than others and whether some groups have a different pattern of usage such as occasional bursts of computation verses steady demand.
The following recipes can be adapted to a variety of such situations.
@@ -37,7 +37,7 @@
Since RANK is an arbitrary {quote: ClassAd} expression, you can customize the policy in a number of ways. For example, there could be a group with second priority on the machines. Or you could specify that some types of jobs (identified by some other {quote: ClassAd} attribute in the job) have higher priorities than others. You just need to write the expression so that it produces a higher number for higher priority jobs.
The down side of RANK is that it involves preemption. RANK only comes into play
-when there is an existing job on a machine and the negotiator is considering whether a new job should preempt it. You can control how quickly the preemption happens in order for the new job to replace the lower priority job using {quote: MaxJobRetirementTime} as described in {wiki: HowToDisablePreemption How to disable preemption}. By default, the preemption will happen immediately. This is most appropriate in Condor pools where groups own specific machines and want guaranteed access to them whenever they need them.
+when there is an existing job on a machine and the negotiator is considering whether a new job should preempt it. You can control how quickly the preemption happens in order for the new job to replace the lower priority job using {quote: MaxJobRetirementTime} as described in {wiki: HowToDisablePreemption How to disable preemption}. By default, the preemption will happen immediately. This is most appropriate in HTCondor pools where groups own specific machines and want guaranteed access to them whenever they need them.
Given a choice of two machines to run a job on, it is a good idea to steer jobs towards machines that rank them higher so they stand less of a chance of being preempted in the future. Here is an example configuration that preferentially runs jobs where they are most highly ranked and secondarily prefers to run jobs on idle machines rather than claimed machines:
@@ -49,11 +49,11 @@
{subsection: How to use group accounting to implement pool shares}
-Whereas startd RANK can be used to give groups preemptive priority on specific machines, Condor's group accounting system can be used to give groups a share of a pool that is not tied to specific machines. The Condor manual section on {link: http://www.cs.wisc.edu/condor/manual/v7.0/3_4User_Priorities.html#SECTION00446000000000000000" Group Accounting} covers this topic.
+Whereas startd RANK can be used to give groups preemptive priority on specific machines, HTCondor's group accounting system can be used to give groups a share of a pool that is not tied to specific machines. The HTCondor manual section on {link: http://www.cs.wisc.edu/condor/manual/v7.0/3_4User_Priorities.html#SECTION00446000000000000000" Group Accounting} covers this topic.
Basically, there are two options:
-*: 1. Identities of individuals can be ignored for purposes of accounting and sharing the pool. Only the group the user belongs to is relevant, and each group has its own priority, which can be weighted as appropriate, and which can be automatically adjusted by Condor's fair sharing algorithm.
+*: 1. Identities of individuals can be ignored for purposes of accounting and sharing the pool. Only the group the user belongs to is relevant, and each group has its own priority, which can be weighted as appropriate, and which can be automatically adjusted by HTCondor's fair sharing algorithm.
*: 2. Individual identities are used when accounting and allocating resources, but each group is assigned a quota of batch slots. If the group is currently using fewer slots than its quota, then its members get preferential treatment when vying for resources.
