{section: How to sample the stack}
 
-This method is useful when you are called in to diagnose a condor daemon that is using lots of cpu (or blocking a lot on I/O) for an unknown reason. Although crude, I have found this method to lead to the source of trouble in numerous cases.
+This method is useful when you are called in to diagnose a HTCondor daemon that is using lots of cpu (or blocking a lot on I/O) for an unknown reason. Although crude, I have found this method to lead to the source of trouble in numerous cases.
 
 If =pstack= or =gstack= are available, just use those.  If not, you can use =gdb=.
 
@@ -23,7 +23,7 @@
 
 Beware that gdb (and gstack) may sometimes leave the process in a trapped state.  Send SIGCONT to the process to let it resume.
 
-If you need to get the condor admin to sample the stack for you, then it is nice to make it even simpler. Below is an example script to do the sampling. (Note that it doesn't load the .dbg file, just to keep things simple.)
+If you need to get the HTCondor admin to sample the stack for you, then it is nice to make it even simpler. Below is an example script to do the sampling. (Note that it doesn't load the .dbg file, just to keep things simple.)
 
 {verbatim}
 #!/bin/sh
@@ -52,7 +52,7 @@
 done
 {endverbatim}
 
-{section: How to use callgrind to profile condor}
+{section: How to use callgrind to profile HTCondor}
 
 Callgrind is a wonderful profiling tool. The one big disadvantage of it is that it slows down the application considerably (~20 times in my experience).
 
@@ -60,7 +60,7 @@
 
 {verbatim}
 condor_off -collector
-# become the user who runs condor
+# become the user who runs HTCondor
 sudo su root
 valgrind &#8212;tool=callgrind /path/to/condor_collector -f -p 9618 >& /tmp/callgrind.log < /dev/null &
 PID=$!