Re: [Condor-users] How good are user priorities obeyed?

[David Anderson <mr.anderson.neo@xxxxxxxxx>]

The behavior I would expect would be that, once one of the A Jobs finishes B would start winning the nodes, and if tts effective priority was much better than  A's then he would pick up all the slots until they equalized.  This is assuming that there is no sort of preemption which is the way I have things operating because I have alot of vanilla/parallel jobs which dont tolerate premption.


The generic policy seemed to keep the claim on a machine for a while and so as long as user A had jobs to run in the queue he held the claim, and it would run his jobs.   With CLAIM_WORKLIFE it seems that after he has held the claim for > CLAIM_WORKLIFE a new negotiation must be done for USER A to have his jobs run, and in this negotiation cycle USER B will beat him because of the better effective priority.


I haven't looked at it in a while, but I did stop getting reports of jobs being queued while someone monopolized the pool. 


I am not sure what the answer is if you expect the USER A jobs to be prempted by USER Bs as that isnt a case that I have even remotely looked at.


David

On Fri, Feb 27, 2009 at 7:34 AM, Carsten Aulbert <carsten.aulbert@xxxxxxxxxx> wrote:

Hi all,

Carsten Aulbert schrieb:

>
> I just checked and we have not set this (or to put it better: it's set
> to a not set variable/macro).
>
> I'll play with that and see how we will fare.
>

I tried CLAIM_WORKLIFE=1800 but that did not do the trick nicely. Again
assuming we had 1000 slots, I pushed 2000 jobs into the queue running
sleep 2400 and after half of them were running I pushed 2000 sleep 600
into the queue by a user with a much better effective prio.
Interestingly, it seems that 2400 is not large enough to be considered
(or the background noise while testing was too large in our pool), but
user A's jobs were still being preferred.

Next step was to set it CLAIM_WORKLIFE=0 which supposedly will be more
stress on the negotiator (at least that what I assume), but at least now
I don't see this phenomenon any more, i.e. user B will get slots as soon
as slots become available again.

So I guess for now the issue is resolved (at least for us).

Cheers and thanks a again David,

Carsten
_______________________________________________
Condor-users mailing list
To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/condor-users

The archives can be found at:
https://lists.cs.wisc.edu/archive/condor-users/

-- 
David Anderson
mr.anderson.neo@xxxxxxxxxxxxxxxx