RE: [Condor-users] Extending Condor's scheduling? (forsched.researchpurposes)

["Ian Chesal" <ICHESAL@xxxxxxxxxx>]

We simply worked within the confines of the condor configuration to
change the behaviour of the system. Our machines rank jobs based on
TARGET.JobPrio and we rely on MaxJobRetirementTime to ensure our scheme
plays nice with our longer running vanilla jobs. It's tipped the fair
share balance, but it's not complete priority based queueing, which is
what we'd prefer (that is, attempt fair share among equal priority jobs
but favour higher priority jobs for execution consideration first over
lower priority jobs).

Ian

> -----Original Message-----
> From: condor-users-bounces@xxxxxxxxxxx 
> [mailto:condor-users-bounces@xxxxxxxxxxx] On Behalf Of David Petrou
> Sent: October 15, 2004 6:18 PM
> To: Condor-Users Mail List
> Subject: Re: [Condor-users] Extending Condor's scheduling? 
> (for sched.researchpurposes)
> 
> 
> Are you implying that you have tweaked the scheduler in another way?  
> (If so, how?)  Or that you didn't do it at all because an interface 
> wasn't available?
> 
> Is there someway to override priority computations to kind of 
> overtake 
> Condor scheduling without source code?
> 
> Thanks,
> david
> 
> > David brings up an interesting point here: access to Condor's
> > scheduling
> > algorithms via an API would be a nice thing. I certainly would have
> > looked to tweaking the scheduler to be non-fair share if an 
> interface
> > had been availble. You wouldn't have to provide source code 
> > necessarily,
> > just a way to replace the library that does the scheduling for the
> > negotiator and matching deamon and then some documentation.
> >
> > Ian
> 
> _______________________________________________
> Condor-users mailing list
> Condor-users@xxxxxxxxxxx 
> http://lists.cs.wisc.edu/mailman/listinfo/condor-users
>