Re: [HTCondor-users] Negotiation Cycles

[Greg Thain <gthain@xxxxxxxxxxx>]

On 09/19/2016 06:02 PM, Kandes, Martin wrote:

Hi all, 

For example, the NEGOTIATOR_INTERVAL sets how often the NEGOTIATOR starts a negotiation cycle. It is defined in seconds and defaults to 60 seconds (or every 1 minute). However, the NEGOTIATOR_UPDATE_INTERVAL determines how often the NEGOTIATOR sends a ClassAd update to the COLLECTOR. This is defined in seconds and defaults to 300 seconds (or every 5 minutes).

Good morning:

The NEGOTIATOR_UPDATE_INTERVAL controls when the negotiator sends the negotiator daemon ad to the collector.  This is the ad that you see when you run condor_status -negotiator -l.

However, a key fact is that this ad isn't used for much, operationally.  It doesn't have detailed information about matches, it is mainly used for tools to find the address of the negotiator.

Briefly, the way the negotiation cycle works is:

1) Negotiator gets all the startd ads and submitter ads from the collector
2) Negotiator gets resource request ads (idle jobs, basically) from schedds
3) Negotiator makes matches, gives out resources to the schedds until done
4) The schedds claim the startds they were given, as soon as they get each one
5) When the startds are claimed, they change state to Claimed, and update the collector with this new state

The delay in the negotiation cycle is to try to ensure that step 5 happens before step 1 happens in the next cycle.  If step 1 of the next cycle DOES happen before 5 of the previous one, the only bad thing that will happen is that a schedd may try to use an expired claim, and may lose out one negotiation cycle.

At some lull in the negotiation cycle, and about every five minutes, the negotiator will update the daemon ad to the collector, but this isn't used for matchmaking.

Make (some?) sense?

_Greg