One implication of negotiator splitting (Consumption Policies) is that the negotiator is responsible for matching all requests. In an large-scale pool, this may make the negotiation cycle the rate-limiter for resource allocation. A pool can support multiple schedulers, so scheduler splitting (CLAIM_PARTITIONABLE_LEFTOVERS) can scale by increasing the number of schedulers running on the pool. {section: Consumption Policies and Accounting} -As was mentioned above, the match cost for a job against a slot with a Consumption Policy is the _change_ in the SlotWeight value from before the match to after. It is this match cost value that is added to the corresponding submitter's usage in the HTCondor accountant. A useful way to think about accounting with Consumption Policies is that the standard role of SlotWeight is replaced with _change_ in SlotWeight. +{subsubsection: slot weights and accounting groups} +When working with Consumption Policies, it is useful to adopt a convention where slot weight represents a measure, or estimate, of *the number of jobs that can be serviced by a slot*. For example, suppose a slot is configured with a very coarse-grained consumption policy for memory. Then memory might be your primary rate limiter: + +{code}CONSUMPTION_MEMORY = quantize(target.RequestMemory, {1024}){endcode} + +So an appropriate slot weight that measures expected jobs that could be serviced by this slot would be: + +{code}SLOT_WEIGHT = floor(Memory / 1024){endcode} + +If the slot has 4096 MB of memory, than the above policy implies that an expected 4 jobs that can be serviced (note that each job consumes at least one chunk of 1024MB). + +Note that job may actually acquire more than one 'chunk' of a resource. Example: if a job ends up taking 2 of the memory quanta defined above (for 2048 mem), it will reduce the partitionable slot's weight from 4 to 2. It is effectively occupying 2 "expected jobs." and it is charged a value of 2, which is deducted against its submitter share, group quota, added to submitter usage, etc. + +An advantage of this convention is that it allows the negotiator's matchmaking to add up the pool's slot weights to obtain a measurement of how many jobs can be serviced by all of the resources. This is especially helpful for working with Accounting Group Quotas, since it makes the one-dimensional group quota computations work smoothly with slots having different consumption policies and different slot weights, and allows compatible comparisons with running and idle jobs. + +{subsubsection: match cost +The match cost for a job against a slot with a Consumption Policy is the _change_ in the SlotWeight value from before the match to after. It is this match cost value that is added to the corresponding submitter's usage in the HTCondor accountant. A useful way to think about accounting with Consumption Policies is that the standard role of SlotWeight is replaced with the change in SlotWeight. + +For example, consider the memory-driven consumption policy above: +{code} +CONSUMPTION_MEMORY = quantize(target.RequestMemory, {1024}) +SLOT_WEIGHT = floor(Memory / 1024) +{endcode} + +Note that a job may acquire more than one of the "chunks" implied by the above policy. Again, assume the slot has 4096MB of memory, for an initial slot weight of 4. Suppose a job acquires 2048MB of that memory. Then the match will reduce the partitionable slot's weight from 4 to 2, for a match cost of 4-2=2. The submitter's usage will increase by 2. Effectively, the job has consumed 2 jobs' worth of that resource (recall that each job consumes at least one chunk of 1024), and is charged accordingly. {section: Heterogeneous Resource Models} Consumption Policies are configurable on a per-slot basis, which makes it straightforward to support multiple resource consumption models on a single pool.