{section: How to suspend jobs in place of preemption}
-Known to work with Condor version: 7.0
+Known to work with HTCondor version: 7.0
-Condor can suspend a process and then later resume right where it left off. This is similar to standard universe checkpointing, except it cannot move the suspended job from one machine to another. The mechanism works with all types of jobs, without any special preparation of the job.
+HTCondor can suspend a process and then later resume right where it left off. This is similar to standard universe checkpointing, except it cannot move the suspended job from one machine to another. The mechanism works with all types of jobs, without any special preparation of the job.
There are two cases where you might prefer suspension in place of killing jobs. One is preemption caused by other activity on the machine (e.g. a user coming back to their desktop). The other is preemption caused by higher priority jobs getting matched to machines that are already busy. Both of these cases are covered below.
{subsection: How to suspend jobs instead of killing them when higher priority jobs need to run}
-There is a section in the Condor Manual on this topic {link: http://www.cs.wisc.edu/condor/manual/v7.0/3_5Startd_Policy.html#SECTION00459600000000000000 here}. The example in the manual requires that you divide jobs into two classes: high priority and low priority. When the high priority jobs arrive on a machine, existing low priority jobs get suspended.
+There is a section in the HTCondor Manual on this topic {link: http://www.cs.wisc.edu/condor/manual/v7.0/3_5Startd_Policy.html#SECTION00459600000000000000 here}. The example in the manual requires that you divide jobs into two classes: high priority and low priority. When the high priority jobs arrive on a machine, existing low priority jobs get suspended.
Below is an example in which the relative priority of the jobs to be suspended and the other class of jobs is left up to the usual mechanisms of startd RANK and user priority. You still have to divide the jobs into two classes: normal jobs and those that should be suspended when they are preempted by normal jobs. This is useful, for example, when you have a special class of jobs which are long running and not checkpointable, but you don't want them to unfairly hog the pool.
@@ -17,7 +17,7 @@
# if you have enough virtual memory to allow the foreground job
# to consume all of memory while the suspended job gets pushed
# into swap memory. There is currently no convenient way to
-# tell Condor you want to oversubscribe your memory, so you
+# tell HTCondor you want to oversubscribe your memory, so you
# have to hard-code the amount of memory you want to advertise
# by uncommenting and filling in the following:
# Memory = TWICE_YOUR_SYSTEM_MEMORY
@@ -93,7 +93,7 @@
{subsection: How to suspend jobs instead of killing them when the machine is busy}
-You just need to make sure WANT_SUSPEND and SUSPEND are true in the cases where you want suspension. The following example is similar to the default policy that ships in Condor's configuration file. It has been made more aggressive in what types of jobs it suspends (everything) and for how long it suspends them before giving up and killing them.
+You just need to make sure WANT_SUSPEND and SUSPEND are true in the cases where you want suspension. The following example is similar to the default policy that ships in HTCondor's configuration file. It has been made more aggressive in what types of jobs it suspends (everything) and for how long it suspends them before giving up and killing them.
{code}
KeyboardBusy = (KeyboardIdle < $(MINUTE))
