There are a few things to keep in mind when interpreting the output of condor_status. The =TotalCpus= and =TotalMemory= attributes are double what the machine actually has, because we are double-counting these resources across the single-core and whole-machine slots.
-When looking at condor_status, the extra slot representing the whole machine is visible. Notice that it appears in the Owner state, because the start expression we have configured is false unless presented with a whole-machine job. We could modify the IS_OWNER expression to make the slot appear as Unclaimed rather than Owner, but we find that Owner is a nice reminder that this slot is special and is not available to run "normal" jobs.
+When looking at condor_status, the extra slot representing the whole machine is visible. Notice that it appears in the Owner state, because the start expression we have configured is false unless presented with a whole-machine job. We could modify the =IsOwner= expression to make the slot appear as Unclaimed rather than Owner, but we find that Owner is a nice reminder that this slot is special and is not available to run "normal" jobs. In fact, it turns out that transitions between Owner and Unclaimed state have an additional important side-effect: they cause the machine to send an updated ad to the collector whenever the machine's willingness to run a job changes. Without this, it can take as long as UPDATE_INTERVAL for the collector to be updated.
+
{verbatim}
$ condor_status
@@ -152,7 +153,7 @@
condor_status -constraint 'IsWholeMachineSlot =!= True'
{endcode}
-When the whole-machine slot is claimed, the other slots will appear in the Owner state, because they are configured to not start any new jobs while the whole-machine slot is claimed. Again, we could make them appear as Unclaimed by changing the IS_OWNER expression, but the Owner state serves as a useful reminder that these slots are reserved during this time.
+When the whole-machine slot is claimed, the other slots will appear in the Owner state, because they are configured to not start any new jobs while the whole-machine slot is claimed. Again, we could make them appear as Unclaimed by changing the =IsOwner= expression, but the Owner state serves as a useful reminder that these slots are reserved during this time, and it has the side-effect of forcing timely updates of the slot ad to the collector.
{verbatim}
$ condor_status
@@ -169,4 +170,4 @@
slot9@execute.node LINUX X86_64 Claimed Busy 0.000 16054 0+00:00:04
{endverbatim}
-Since the whole-machine policy depends on STARTD_SLOT_EXPRS, it can take a few iterations of =ClassAd= updates for the state of the slots to converge. For this reason, the information visible in condor_status may lag behind the true state of the slots when conditions have recently changed. It is therefore useful to use the -direct option to condor_status when verifying that the whole-machine policy is correctly working.
+Since the whole-machine policy depends on STARTD_SLOT_EXPRS, it can take a few iterations of =ClassAd= updates for the state of the slots to converge. For this reason, the information visible in condor_status may lag behind the true state of the slots when conditions have recently changed. It is therefore useful to use the -direct option to condor_status when verifying that the whole-machine policy is correctly working. As noted above, with =IsOwner= set in the default way so that slots enter the =Owner= state when they are unwilling to run new jobs, the information published in the collector will be updated much more quickly than if =IsOwner= is set to false. It is therefore highly recommended that =IsOwner= not be set to false.
