Using Computer Time

This page discusses several issues involved in the use of UNIX computers

Denial of Service Attacks

When done maliciously, tying up a computer is called a denial of service attack. When done through ignorance or thoughtlessness, it is not called an attack, but it is just as annoying and just a inconvenient for other users.

There are many ways to tie up computers so other users can't use them, or can't get full use of them. Some are detailed below. Don't do any of them, but also don't do anything else that makes the computers unavailable or less useful for other users.

Screen Locks

Tying up a computer for long periods of time is unacceptable. It is reasonable to "lock" the console (using the "lock" icon on the front panel) while you have left the computer room for a few minutes. It is not reasonable to leave the lock for many minutes. If you're not using the computer, then log out and let other people use it.

Background Jobs

In UNIX jobs can be run in the background by putting an ampersand (&) after the command. For example, to run a program a.out in the background, do

   a.out &
The program will run until it finishes (or crashes, or the computer crashes or reboots). You can log out and let others use the console.

You can also put a job that is already running in the background. First stop it with Control-Z. Then put it in the background with the bg command. For example,

   isles% a.out
   ^Z
   Suspended
   isles% bg
   [2]    a.out &

Before running a big job, be sure that it works! Write your program so that you can run a small test set first. This will save you and everyone else a lot of time should something be amiss in your program.

Finding Out Which Jobs are Running

If you want to check whether your job is still running you must log into the same computer and use the top command to look at jobs. (You can also use the ps command, but we won't explain that. See the man page.) Saying

   top
at a UNIX prompt will start the top program which displays something like this
   System: isles                                         Mon Aug  9 13:04:22 1999
   Load averages: 1.09, 1.06, 1.06
   99 processes: 97 sleeping, 2 running
   Cpu states:
    LOAD   USER   NICE    SYS   IDLE  BLOCK  SWAIT   INTR   SSYS
    1.09   2.1%  95.0%   2.9%   0.0%   0.0%   0.0%   0.0%   0.0%

   Memory: 26320K (24144K) real, 77644K (69192K) virtual, 1860K free  Page# 1/8

    TTY   PID USERNAME PRI NI   SIZE    RES STATE    TIME %WCPU  %CPU COMMAND
      ? 20453 doug     255 39 17796K  8728K run    512:10 94.73 94.56 a.out
      ? 20835 charlie  179 20   308K   288K run      0:00  5.87  1.94 top
      ?  1074 daemon   154 20  8336K  3792K sleep    6:25  1.06  1.05 X
      ?  1145 charlie  154 20   436K   640K sleep    0:29  0.64  0.64 dtterm
      ?  1126 charlie  154 20   420K   532K sleep    0:44  0.39  0.39 dtterm
      ?     0 root     127 20     0K     0K sleep    0:44  0.23  0.23 swapper
and more of the same to make a screenfull. We are interested in the last column (COMMAND). We see that a.out is still running. Later when we discuss niceness, we will also be interested in the NI column. To leave top type q.

Priority (Niceness)

All background jobs should be niced using the UNIX nice or renice commands.

UNIX has a priority system for running processes. The priorities allowed for ordinary users run from 20 to 39. The system uses priorities from 0 to 19. Ordinary users foreground jobs run at priority 20 as can be seen from the top output above, most of the numbers in the NI column are 20 indicating default priority and are foreground jobs. The background job a.out is running at priority 39, which is the lowest possible priority. It runs only when other programs aren't using the computer's CPU, but since all the other jobs are interactive, they spend most of their time waiting for user input. Despite having the lowest possible priority, a.out is getting almost all of the CPU time (94.56% of the CPU time according to the %CPU column).

Thus we see there is no good reason to run background jobs at default priority. They will get the lion's share of the CPU time regardless of priority. Running at the default priority will not make them finish sooner, but it will make the response of the computer slower for anyone using the console.

Thus you should always run a job niced, doing, for example,

   nice +19 a.out &
to start your job in background. This will give it priority 39 (19 more than the default), the lowest possible.

When you stop a foreground job and put it in the background using Control-Z and bg, you can use the nice command. You must instead use the renice command. The syntax is

   renice -n 19 PID
where PID is the PID of the process found in the PID column of top output. For example, to renice a.out in the example output above, one would do renice -n 19 20453 (of course, this wouldn't do anything since the program was already at that priority, the only point is to give an example with the PID filled in).

Running Multiple Jobs (Different Machines)

The current policy on the workstations is to allow one background or big job per public machine per user. You should not use the faculty or private workstations unless you have received permission from the faculty member in advance.

If you need to run on multiple machines, ask. If it won't get in anyone's way, that's fine. They are there to be used.

Running Multiple Jobs (Same Machine)

From the standpoint of saving computer time, there is no point to running more than one job at a time on the same machine. The machine has only one CPU. It can only run one program at a time. It only appears to run many programs at once by time-slicing, changing which progam has the CPU every few milliseconds. Running multiple jobs simultaneously actually makes them run slower, perhaps much slower, because of the switching overhead.

Sometimes, however, you want to start a bunch of different jobs and log out and go home. You won't be there to start them in succession as the previous ones finish. Thus you are tempted to start them all at once.

Don't. Here's how to accomplish what you want without bogging down the computer, making it unusable for anyone else (and also increasing the risk of a crash that wipes out your work).

Run your jobs in succession using a shell script, which you background. Suppose you have three S-PLUS jobs you want to run. Put them in a file (say sjobs)

   #!/usr/local/bin/tcsh -f
   Splus < commands1 >& bleat1
   Splus < commands2 >& bleat2
   Splus < commands3 >& bleat3
The first line is a UNIX magic incantation. You don't need to understand it, just use it. There is no left hand indentation, #! are the first two characters of the file. Note these commands do not put the S-PLUS jobs in background (there is no ampersand at the end of any line). Then make this file executable and run it in background and niced.
   chmod +x sjobs
   nice +19 sjobs &

Author: Charles Geyer (charlie@stat.umn.edu). Comments or corrections gratefully accepted.