[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [condor-users] RE: clarification required please



> -----Original Message-----
> From: owner-condor-users@xxxxxxxxxxx
> [mailto:owner-condor-users@xxxxxxxxxxx]On Behalf Of Alain Roy
> Sent: 10 May 2004 23:25
> To: condor-users@xxxxxxxxxxx
> Subject: Re: [condor-users] RE: clarification required please
<snip> 
> 
> >which is true?
> 
<snip>
> 
> Uhh... Does grep work on Windows? If not, just skim the 
> output and look for 
> the CurrentRank.

does with cygwin :¬)
 
> 
> Perhaps the real question is "what should CurrentRank be?".

Indeed I should have written which is meant to be true. since I was planning on providing a quick (and very dirty) app to allow the vacation of an arbitrary number of machines at user request but only taking out those of lesser rank. I think I will steer clear of assuming a negative value indicates no job running and wait for 6.7.1
 
> >B) Preemption
> >from the supplied config file
> >
> >##  The negotiator will not preempt a job running on a given machine
> >##  unless the PREEMPTION_REQUIREMENTS expression evaluates to true
> >##  and the owner of the idle job has a better priority than 
> the owner
> >##  of the running job.  This expression defaults to true.
> >UWCS_PREEMPTION_REQUIREMENTS = $(StateTimer) > (1 * $(HOUR)) && 
> >RemoteUserPrio > SubmittorPrio * 1.2
> >
> >does this means that, in addition to this PREEMPTION_REQUIREMENTS 
> >evaluating to true the user prio must be better or that this 
> particular 
> >expression causes this.
> 
> The condor_negotiator checks the priority internally as well.

I have two different replies to this now (ref: Mark Silberstein)

Since I have set the priority_halflife to 1 second to make prior user load immaterial in assigning the user priorities will never be significantly different except while jobs are running. Will this change negatively impact other internal processes/optimizations expecting a significant value?
 
> >C) Vacation
>
> >vanilla jobs do not immediately go to the killing state they 
> remain in the 
> >preempting state till the timeout expires (we were using the 
> default UWCS 
> >value for KILL as I thought it would not matter)
> 
> I suspect that this is a bug in the documentation, not in the 
> code. I will 
> ask someone else to weigh in on this, and maybe fix the 
> documentation if 
> necessary.

The state transition diagram in the docs is pretty clear. want_vacate = false; go straight to killing, do not pass go, do not collect a checkpoint. (which makes sense)

Thanks,
Matt


*****************************************************************
Gloucester Research Limited believes the information 
provided herein is reliable. While every care has been 
taken to ensure accuracy, the information is furnished 
to the recipients with no warranty as to the completeness 
and accuracy of its contents and on condition that any 
errors or omissions shall not be made the basis for any 
claim, demand or cause for action.
*****************************************************************

Condor Support Information:
http://www.cs.wisc.edu/condor/condor-support/
To Unsubscribe, send mail to majordomo@xxxxxxxxxxx with
unsubscribe condor-users <your_email_address>