Re: [Condor-users] slight bug in dynamic slots

[William Henry <whenry@xxxxxxxxxx>]

It seems fair enough but presumably has some overhead. Is it reasonable to allow the carving out of the slot again when there might be 100s of similar jobs.

Consider a workflow that has 100s of repeating similar jobs.  It might be nice for the CLAIM to stay around so as not to return it to the dynamic slot and have to be re-carved. However perhaps that overhead is minimal.

I just wonder is there a better way to NOT match lesser jobs with the larger slot.  But if the overhead of return/re-carve is not too large then it seems like the right thing to do.

William 

----- Original Message -----
> That does suggest that the system should default CLAIM_WORKLIFE to
> zero for dynamic slots... can anyone think of a reason *not* to always
> do that?
> 
> -----Original Message-----
> From: condor-users-bounces@xxxxxxxxxxx
> [mailto:condor-users-bounces@xxxxxxxxxxx] On Behalf Of Lukas Slebodnik
> Sent: 16 May 2011 15:49
> To: Condor-Users Mail List
> Subject: Re: [Condor-users] slight bug in dynamic slots
> 
> Hi Erik,
> 
> You can change tihs behaviour by setting variable CLAIM_WORKLIFE.
> http://www.cs.wisc.edu/condor/manual/v7.4/3_3Configuration.html#16308
> 
> This variable specifies the number of seconds after which a claim will
> stop
> accepting additional jobs.
> 
> Regards,
> Lukas
> 
> On Mon, May 16, 2011 at 10:35:40AM -0400, Erik Aronesty wrote:
> > When a job on a dynamic slot (slot1.1 for example) completes, the
> > dynamic slot is marked as "available/unclaimed" for a brief window
> > of
> > time before it is reaped and the resources it consumes are made
> > available to the primary slot (slot1).
> >
> > During that time a job can be scheduled on it.... a job with far
> > less
> > RAM or #CPUS than the slot has reserved.
> >
> > This results in a large inefficiency in job allocation when the
> > queue
> > is very busy, and there are lots of mixed jobs... some reserving
> > high
> > numbers of cpus and others reserving few.
> >
> > - ERik
> _______________________________________________
> 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/
> 
> --------------
> 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.
> The information in this email is intended only for the named
> recipient. If you are not the intended recipient please notify us
> immediately and do not copy, distribute or take action based on this
> e-mail.
> All messages sent to and from this email address will be logged by
> Gloucester Research Ltd and are subject to archival storage,
> monitoring, review and disclosure.
> Gloucester Research Limited, 5th Floor, Whittington House, 19-30
> Alfred Place, London WC1E 7EA.
> Gloucester Research Limited is a company registered in England and
> Wales with company number 04267560.
> --------------
> _______________________________________________
> 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/