RE: [Condor-users] When do machine RANK settings apply?

["Ian Chesal" <ICHESAL@xxxxxxxxxx>]

Thinking more about this now. See below. 

> I'm not answering my own question here. I'm adding to it. See below...
> 
> > Do machine RANK settings apply before or after resources are 
> > partitioned based on effective priority? I'm not certain I 
> completely 
> > understand a negotation cycle in condor. Lets say I have one free 
> > machine and a cycle starts. I have users with idle jobs 
> that have user 
> > A with 2 idle jobs with job priorities 1 and 2. I have user 
> B with 2 
> > idle jobs with job priorities 3 and 4. User A has an EUP of 
> 2.00 and 
> > user B has an EUP of 2.00. when the negotiation cycle 
> starts, how will 
> > that one lone free machine be handled: how can I predict which user 
> > will get the machine?
> > 
> > If the RANK on the machine was:
> > 
> > RANK = TARGET.JobPrio * 1000
> > 
> > Then should the machine not go to the job with the highest job 
> > priority value? I'm seeing it go to User A's job.
> 
> Sitting and thinking some more. If I have 100 vm's in my 
> system. And 100 users, each with infinitly long queues of 
> jobs. Over time will each user's EUP move to 1? Will each 
> user end up using exactly 1 machine in the system as 
> steady-state is reached? Have I understood this correctly?
> 
> If I artificially reset all RUPs to 0.50 every minute 
> (basically cron a call to "condor_userprio -resetall") -- 
> would this get me to the priority-based queueing utopia I 
> desire? If everyone's EUP is always as low as it can be, so 
> all resources are equally likely to be assigned to each user, 
> will RANK statements not take over to decide which jobs take 
> up to a free machine? Am I way off here with my understanding 
> of how this works?

A little more thought a re-read of section 3.5 of the manual and now I'm
wondering if I could eliminate preemption based on user priorities by
simply changing the PREEMPTION_REQUIREMENTS. Currently I have:

PREEMPTION_REQUIREMENTS = (CurrentTime - EnteredCurrentState) > (1 * (60
* 60)) && RemoteUserPrio > SubmittorPrio * 1.2

Can I drop the RemoteUserPrio > SubmittorPrio * 1.2 portion and prevent
preemtion based on condor-calculated priorities all together? We don't
out-right secede our machines to preemption requests -- we use a very
long MaxJobRetirementTime setting to give jobs 2 days to finish when a
preemption request is issued. We run vanilla jobs. Would losing this
portion of the PREEMPTION_REQUIREMENTS setting ensure that preemption
would never occur because of condor-calculated priorities? I'm looking
back over the mailing list archives and based on a thread started by
Matthew Hope I think this might be the answer to my trouble. For the
record I am trying to make Condor behave in a priority-like queuing
manner.

And on the side RemoteUserPrio and SubmittorPrio are not defined in the
documentation. At least the Adobe Acrobat search tool couldn't find any
reference to these class ad attributes.

- Ian