> From: Thilo Manske <Thilo.Manske@HEH.Uni-Oldenburg.DE>
>> :::
> With nice=0 for the dhry2 run everything is ok:
>
>   PID USERNAME PRI NICE   SIZE   RES STATE   TIME   WCPU    CPU COMMAND
>  2838 thilo     64    0   168K  280K run     4:24 97.75% 97.75% dry2
>   362 thilo     68   20    13M   14M run   668:48  0.00%  0.00% setiathome
>
> When I renice it to 5, seti starts eating cycles:
>
>   PID USERNAME PRI NICE   SIZE   RES STATE   TIME   WCPU    CPU COMMAND
>  2838 thilo     74    5   168K  280K run     5:25 91.26% 91.26% dry2
>   362 thilo     79   20    13M   14M run   668:51  6.88%  6.88% setiathome
>
> The manpage should be corrected to something like:
> "when nothing else in the system with nice<=0 wants to"
> Or the scheduler needs a fix. IMHO you should send-pr(1) this.

You must be running 1.4 or post-2/99 -current

Anyway, I'm fairly certain that the current behavior is what we want, so
I've just fixed the man pages. :-)

The idea is that nice +19 or nice +20 does not compete at all with the
default nice +0. Intermediate ranges of niceness cause more or less
competition inversely with respect to nice +0 and directly w.r.t. nice +19.

Consequently, nice +10 (the default for nice(1)) is the recommended priority
value for programs that you want to eventually complete regardless of load
while substantially minimizing their impact.

nice(3) trivia notes:

   1.	nice +19 is guaranteed to not compete, as opposed to merely
	nice +20, because not all versions of unix even have a nice +20
	and +19 was the historical non-competing guarantee.)

   2.	the csh(1) nice built-in has a strange default of +4; this is
	not very nice.

ross.harvey@computer.org