Re: [Condor-users] Efficiently using a inhomogeneous cluster

[Steffen Grunewald <steffen.grunewald@xxxxxxxxxx>]

On Thu, Jun 14, 2007 at 10:03:01AM -0500, Dan Bradley wrote:
> 
> NEGOTIATOR_POST_JOB_RANK sounds like a good fit for what you are trying 
> to do, with one proviso.  The idea is that the user ranks things in some 
> way (e.g. by Mips) that produces a bunch of top-choice machines that all 
> have the same rank.  The negotiator's "post job rank" is then used to 
> choose the lowest memory machines from among those choices.

In theory, we are talking about (CPU-wise) homogeneous machines.
The problem with Mips and kFlops is that these values are fluctuating and
can be trusted only to some error margin.
In practice this means that *not* all machines will have the same rank,
and the distribution of the big-memory ones will be random.

> The problem with that plan is that if some or all of your high memory 
> machines also happen to have high Mips, then users A and B will happen 
> to rank them higher than low memory machines, so the negotiator's post 
> job rank won't help.  If that is a problem for you, then I can't think 
> of a better option than to have user C explicitly identify jobs that 
> want lots of memory.  Example:
> 
> +WantBigMemory = True
> 
> Then you could use the negotiator's pre job rank (which precedes the 
> user's specified rank rather than following it in the sort order).  Example:
> 
> NEGOTIATOR_PRE_JOB_RANK = (WantBigMemory =!= True) * -Memory

There are three kinds of users I have to consider:
(a) the ones who don't specify memory requirements (and run the risk that
	their jobs won't fit on the machine matched, but there's swap)
(b) the ones who *specify* low memory requirements
(c) the ones who specify *big* memory requirements

Obviously, types (a) and (b) can be handled the same.
Looking into the manual, subsection 3.4.5, I can see that user (c) will
not be matched against low-memory machines. That's OK. Users (a)/(b) on
the other hand will be matched wil all machines, so indeed NEGOTIATOR_PRE_JOB_RANK
will be the next selection criterion, and indeed this one has to be lower
for big-memory machines. No more magic required.

NEGOTIATOR_PRE_JOB_RANK = -Memory

(I'm unsure about the syntax here, no parentheses, no dollar sign, no
TARGET prefix?)

What this will do:
(a)/(b) will be scared off big-memory machines as long as there are low-
memory machines available (unclaimed). If all those are used up, they will
get access to big-memory machines, so no resources are blocked.
(c) by the first negotiation rule will end up with only the machines that
match her requirements, and again will be matched with the lowest-memory
machines matching the specified requirement first.

Will it?


Cheers, 
 Steffen