Nice value worthless??? / Renice?

[T. William Wells]

In article <1800006 at spdyne> root at spdyne.UUCP writes:
: I have a question about the nice values of processes:
:
:       Now I'm running a Compaq 386/20, with (sorta slow drives (40ms)),
: and only 3 Meg of ram.  Microport UNIX with DOS-MERGE. (Sys V)
:
: As far as I can tell, the nice value does absolutly nothing!
: I have been running my makes +19 to allow other things to run and
: I can't even page up/down in VI in under a few seconds.
: It takes the same amount of time even if I nice -20, so what good does it
: do?
:
:       Is it just the way that Sys V works or is it just that I don't have
: squat for ram?  (Merge wants 2.6 Meg), Slow disks?  (I know that the
: CPU waits on the transfer - right?)

	(Sort of: the requesting process waits for the disk, but
	anything that isn't waiting for the disk can run.)

I'm pretty sure that it is the seek time on the disks. Consider the
following scenario: two processes, each accessing the disk, with the
parts of the disk being accessed being fairly far apart. Each process
computes for a time less than half the seek time between their
sections of the disk. (The half comes because of read-ahead.)

When the first process waits on the disk, the second one goes; then
both are blocked waiting for the disk.  Finally, the first process
gets its disk blocks and the disk seeks for the second processes'
blocks. The first process does its thing, but blocks waiting for the
disk, before the second set of blocks are available.  Then, when
those blocks become available, the two processes switch roles. At no
time other than the beginning are the two processes contending for
the CPU; therefore, the nice value makes no difference.

There are two ways to fix this: either increase the amount of data
read after a seek, so that the processes block less frequently
waiting for a seek (and thus bringing them into contention) or using
the nice value to help control the disk queue. Note that doing the
latter can actually hurt performance if not done carefully.  Note
also that both of these are kernel changes, we users can't fix them.

The amount of RAM might also make a difference, by increasing the
amount of paging being done. When I brought up my system, it used a
ridiculous amount of disk buffers; when I reduced it to something
reasonable, my system performance improved dramatically since those
ex disk buffers were now available for process space.

Here's an oddity for you: running a third, compute-bound, process can
actually improve your response time! What it does is to provide
contention with the lower priority process so that that process runs
less often.  Because it runs less often, the disk seeks less
frequently, thus permitting your higher priority process to get its
data more quickly.

I did the experiment. Here is the script I used:

	# initial nice is absolute 0, i.e., the max
	# the input files are big (words is 791837)
	# and /tmp is far from /usr (they are separated by my swap space)
	exec >t.out 2>&1
	time          sed s/a/A/ </tmp/words >/dev/null &
	time nice -20 awk 'BEGIN { for (i = 0; i < 10000; ++i) ; }' &
	time nice -40 sed s/a/A/ </usr/words >/dev/null &
	wait
	wait
	wait

Here are the timings:

clock  47 CPU 44 This for running one of the sed's by itself

clock  72 CPU 71 This for running the awk by itself

clock 162 CPU 52 This for both of the sed's running at the same time
clock 162 CPU 52

clock  57 CPU 44 This with everything: (first sed)
clock 168 CPU 74                       (awk)
clock 152 CPU 44                       (second sed)

As you can see, by running the awk in the background, the initial sed
runs almost as quickly as it would on an unloaded system.

Ah, the perils of process scheduling!

---
Bill
{ uunet!proxftl | novavax } !twwells!bill