Re: [Condor-users] our ideal configuration

[Steffen Grunewald <steffen.grunewald@xxxxxxxxxx>]

On Fri, Jun 29, 2007 at 10:47:49AM +0200, Horv?tth Szabolcs wrote:
> Hi,
> 
> I was trying to find the ideal configuration settings for our needs and 
> although part of it works nicely I still could not
> get everyting working as intended. Any tip, example or experience with 
> similar setups is much appreciated!
> 
> - No preemtion.

Think about 
WANT_SUSPEND = False
WANT_VACATE = False
SUSPEND = False
CONTINUE = True
PREEMPT = False
KILL = False
PREEMPTION_REQUIREMENT = False
and the like, and also have a look at the CondorWeek 2007 presentation about
large compute clusters.

> - The job execution order should be controlled by custom job attributes 
> (low/mid/high priority) and the execution
> order should respect both this setting and condor job priority. User 
> priority should balance job count between
> users but an important task should run in spite of user priority. 
> Important stuff should be out the door as fast as it can be
> without preemption.

Use RANK, NEGOTIATOR_{PRE,POST}_JOB_RANK
Question is, would you let the users specify whether their job is high-prio?
Would you seriously expect users to rank their stuff low-prio??
Who would define whether stuff is "important"?
To let others in, use CLAIM_WORKLIFE (keep it low, and "new" users will 
be allowed to run jobs as long as their dynamic priority is better than
the one of the long-time user)

> - Job execution should be as much first-in-first-out as can be but it 
> should respect attribute changes of the users.

Choose a short PRIORITY_HALFLIFE.

> - DAGs of a user should run one after the other: by default if maxidle 
> or maxjobs flags are used and more dags
> are submitted than the execution of jobs gets mingled between DAGs, they 
> run in the order of job submission.
> I'd like to have the first submitted dag complete and only then start 
> the jobs of the next one.

I don't know how to handle this. Somehow it's against the concept of Condor
(which aim at High Throughput, not high fairness or whatever)

S

-- 
Steffen Grunewald * MPI Grav.Phys.(AEI) * Am Mühlenberg 1, D-14476 Potsdam
Cluster Admin * http://pandora.aei.mpg.de/merlin/ * http://www.aei.mpg.de/
* e-mail: steffen.grunewald(*)aei.mpg.de * +49-331-567-{fon:7233,fax:7298}
No Word/PPT mails - http://www.gnu.org/philosophy/no-word-attachments.html