Re: [Condor-users] Q: What (if any ) configuration variables can be tweaked to reduce flocking times?

[Dan Bradley <dan@xxxxxxxxxxxx>]

It should help to set NEGOTIATOR_INTERVAL and NEGOTIATOR_CYCLE_DELAY in 
your submit pool to something very small (like 10 seconds).

Another option would be to configure things a little differently so that 
the schedd treats the flocking pool as its "home" pool so that there is 
no flocking delay at all.

SCHEDD.CONDOR_HOST = execute.central.manager

That might just work, but if you have problems because the schedd is not 
advertising itself to the submit pool, you could set

FLOCK_TO = submit.central.manager

That way, the schedd will advertise itself in both pools.

--Dan

Dickens, Ian W. wrote:
> History:
>
> I have to pools – 1 pool simply for submitting/injecting jobs into a 
> second pool using flocking. I chose this method as a means of removing 
> the users using several submit stations in the first pool from 
> interacting/seeing/knowing anything running in the second pool (trying 
> to build a black box) – policy forbids anything executing in the first 
> pool. Anyway, it sometimes takes up to 5 minutes before the jobs 
> submitted realize from taking to the master in the first pool it 
> cannot run in that world and needs to flock. Using version 7.3.1 are 
> there and variables that could be tweaking in either the first pool or 
> second which might decrease the lag? I would love something in the 
> first pool which basically does a FLOCK_ONLY setting :D
>
> Many thanks in advance,
>
> Ian
>
> ian@xxxxxxxxx
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/
>