Re: [Condor-devel] sorting of groups in negotiation cycle

[Dan Bradley <dan@xxxxxxxxxxxx>]

On 5/23/11 1:25 PM, Brian Bockelman wrote:
> On May 23, 2011, at 1:18 PM, Erik Erlandson wrote:
>
> > On Mon, 2011-05-23 at 13:08 -0500, Brian Bockelman wrote:
> >
> > > Does the negotiator correctly compute the number of weighted slots?  We hit that issue locally - starvation was occurring because the negotiator thought there was about 1,000 extra slots and it way-overallocated some groups.  Until the sorting is implemented, this is one way to approach things.
> >
> > Hi Brian,
> >
> > By default, the negotiator uses the weighted slot totals as its starting
> > point for computing quotas.  If you'd prefer that to not happen, you can
> > configure:
> >
> > NEGOTIATOR_USE_SLOT_WEIGHTS = FALSE
> Yeah - but that's only with slot weights.  What if you happen to have too many slots (i.e., some sites throw in a per-node management slot)?  This can be enough to cause starvation.

Just to be clear here.  Do we believe there is actually a problem with 
slot weights != 1?  Or are we just talking about the more general 
problem of starvation in an inhomogeneous pool where people early in the 
cycle get their hands on the most desired slots before other less lucky 
people get a chance?

In addition to the GROUP_DYNAMIC_MACH_CONSTRAINT knob that Brian 
mentioned, another approach is to use the new, equally undocumented 
GROUP_QUOTA_ROUND_ROBIN_RATE.  The latter may help in cases where you 
truly have inhomogeneous slots, not just a set of special-purpose slots 
that are rarely under contention.

--Dan