[Condor-users] Re: preemption (again)

[matthew hope <matthew.hope@xxxxxxxxx>]

can I confirm the following setup will work in a high volume setting
(I have no way of testing it without taking the farm out of commision)

if I get to 6.7.x (would go with .2)

on the worker nodes:

START = (JobStart =?= UNDEFINED) || (JobStart < CurrentTime - (30 * $Minute) )
PREEMPT = FALSE
RANK = ((TARGET.TIER =?= "Critical") * 1000) + ((TARGET.TIER =?= "High") * 100) 
+ ((TARGET.TIER =?= "Normal") * 10) + ((TARGET.TIER =?= "Low") * 0) 
+ ((TARGET.TIER =?= "Mild") * 5)

on the negotiator

PREEMPTION_REQUIREMENTS = FALSE

Will this mean that a higher ranked job will preempt a lower ranking
one if the current job has only been running for 30 mins?

Will the altered Start statement cause issues during the transition
from Claimed->Idle to Claimed->Busy under high load? Last time I tried
any kind of cleverness in the Start experession it failed miserablly
due to problems with this so I'm loath to repeat it.

The loss of throughput I'm getting through not being able to prevent
preemption without disabling the tiering is a nightmare...

Matt

On Wed, 6 Oct 2004 09:47:23 +0100, matthew hope <matthew.hope@xxxxxxxxx> wrote:
> I am moving onto testing 6.7.1 and was rereading through the manual
> (much better by the way) for a refresher
> 
> got to
> 
> http://www.cs.wisc.edu/condor/manual/v6.7/7_3Running_Condor.html#SECTION008311000000000000000
> 
> <quote>
> Reason number 3 is the owner (machine) preference: controlled by the
> RANK expression in the configuration file (sometimes called the startd
> rank or machine rank). The RANK expression is evaluated as a floating
> point number. When one job is running, a second idle job that
> evaluates to a higher RANK value tells the condor_ startd to prefer
> the second job over the first. Therefore, the condor_ startd will
> evict the first job so that it can start running the second
> (preferred) job. For more on RANK, see section 3.6.
> </quote>
> 
> This implies that it is impossible to mantain a tiered ranking (or
> indeed any other worker controlled ranking) at the same time as
> avoiding preemption...is this correct?
> 
> This is a real PITA, can there not be another parameter which allows
> the control of this process (akin to PREEMPTION_REQUIREMENTS).
> 
> I know I can ameliorate the problem with retirement settings but this
> is very annoying.
> 
> It is reasonable to assume that just because a machine prefers a job
> does not mean it automatically wants to preempt its current one
> surely...
> 
> Matt
>