Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zephyr.ens.tek.com!tektronix!reed!intelhf!ichips!inews!hopi!bhoughto
From: bhoughto@hopi.intel.com (Blair P. Houghton)
Newsgroups: comp.unix.internals
Subject: Re: "Nice" or not to "nice" large jobs
Summary: My empirical alter-ego adds some data to the fire
Keywords: scheduling priority nice
Message-ID: <4293@inews.intel.com>
Date: 19 May 91 09:44:02 GMT
References: <3197@sparko.gwu.edu> <1991May16.140622.29266@alchemy.chem.utoronto.ca> <4281@inews.intel.com>
Sender: news@inews.intel.com
Organization: Intel Corp, Chandler, AZ
Lines: 112

In article <4281@inews.intel.com> bhoughto@hopi.intel.com (Blair P. Houghton) writes:
>In article <1991May16.140622.29266@alchemy.chem.utoronto.ca> system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes:
>>Our policy for nice/renice is:
>>
>>0  - "short" processes/jobs (compilations, or up to 5 minutes cpu time).
>>1  - "medium" processes/jobs (up to 1 hour cpu time).
>>2  - "long" processes/jobs (all other jobs).
>
>That's all but affectless.

I flame myself.

Computer usage is a chaotic system, and as such deserves
a more empirical method.

Check out these stats, collected over 10 minutes of
real-time run of 3 simultaneous, identical processes (3
fork/exec's of the same executable, which was essentially a
tight loop testing and incrementing a couple of integers)
on a relatively quiescent machine (a VAX420 (a DECstation3100)
running Ultrix with a load of about 0.08):

    nice    cpu user-mode time (out of 600 sec)

    0       212.39 sec      35.4 %
    1       199.07          33.2
    2       185.34          30.9

    total   596.80          99.47 %

thus, each step in nice value gives about a 2.3
percentage-point split in cpu-time share.

When the processes are perturbed by another process that
simulates a user interface (extraneous load about 1.0 with
occasional i/o, intermittent computation, and light shell
activity):

    nice    cpu user-mode time (out of 600 sec)

    0       204.51 sec      34.1 %
    1       190.29          31.7
    2       179.59          29.9

    total   574.39 sec      95.7 %

this shows little change in the splits.

If we multiply the nice values by 4:

    nice    cpu user-mode time (out of 600 sec)

    0       285.40 sec      47.6 %
    4       181.63          30.3
    8       129.87          21.7

    total   596.90 sec      99.4 %

this simple increase causes the splits to increase
to approximately 17 percentage-points each.

Using the larger-grained and offset nice values I suggested
for the cpu-intensive processes:

no interference:

    nice    cpu user-mode time (out of 600 sec)

    4       306.26 sec      51.0 %
    8       169.23          28.2
    12      121.31          20.2

    total   596.80 sec      99.5 %

random, light i/o in another process:

    nice    cpu user-mode time (out of 600 sec)

    4       307.65 sec      51.3 %
    8       158.50          26.4
    12      107.60          17.9

    total   573.75 sec      95.6 %

The effect on the lower-priority processes is much
more noticeable, to the point that using nice becomes
actual management of the time the processes use.

As a finale, I present 10 processes fighting over an
otherwise quiet (load < 0.1) cpu:

    nice    cpu user-mode time (out of 600 sec)

    0       354.09 sec      59.0 %
    2       120.83          20.1
    4       56.52           9.42
    6       38.15           6.36
    8       21.03           3.51
    10      5.07            0.845
    12      1.75            0.292
    14      0.38            0.063
    16      0.32            0.053
    18      0.20            0.033

    total   598.34 sec      99.72 %

when graphed, this is a fairly smooth curve with half
of the processes taking over 100 times their optimal
run-time to complete...

				--Blair
				  "Empires are for empiricists."