> 1) Let's say if team A has the job running on cluster, as soon as the job
> is submitted by team MC, it should preempt the team A job.
> 2) If team MC job is running for more than 2 hours and other team jobs are
> waiting then team MC job should get preempted.
    Suppose that exact sequence of events happens: team A has a
running job, a team MC job preempts it, and the team MC job runs for two
hours. Then a team A job preempts the team MC job, but is immediately
preempted by a the team MC job, because team A has a runinng job and team
MC had an idle job. I think you need to say something like "only team MC
jobs which haven't already run for two hours preempt" to get a workable
policy.
    Regarding the implementation of the policy, it may well be easier
to the configure the favored schedds to explicitly mark their jobs than to
extract the identity of the schedd from the job ad.
> I read about 4 reasons of preemption, it seems like that PREEMPT (owner
> machine policy) will be more appropriate to achieve the task.
    You may want to use RANK-based preemption -- if I recall
correctly, the startd otherwise doesn't ever get to compare the running
job to the candidate job.
- ToddM
_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
The archives can be found at:
https://lists.cs.wisc.edu/archive/htcondor-users/