Xref: utzoo comp.unix.xenix:4625 comp.unix.wizards:14326
Path: utzoo!attcan!uunet!lll-winken!ames!hc!pprg.unm.edu!unmvax!tut.cis.ohio-state.edu!rutgers!att!whuts!homxb!homxc!dwc
From: dwc@homxc.ATT.COM (Malaclypse the Elder)
Newsgroups: comp.unix.xenix,comp.unix.wizards
Subject: Re: Changing the nice() value of a running process.
Keywords: Can someone explain why?
Message-ID: <5146@homxc.ATT.COM>
Date: 24 Jan 89 03:06:57 GMT
References: <363@lilink.UUCP> <8818@alice.UUCP>
Organization: Legion of Dynamic Discord
Lines: 22

In article <8818@alice.UUCP>, debra@alice.UUCP (Paul De Bra) writes:
> 
> To find out whether your apparent improvement is real you should measure
> the time needed to solve queries. Cursor response is deceiving.
> 
it is arguable that cursor response is the most important
measure since it is EXPECTED to be almost instantaneous while
database queries are EXPECTED to take a while.  but i agree
that the original poster is probably penalizing the database
backend process in favor of the interactive front end processes.

the problem will come if/when the cpu requirements of the
terminal processes ALONE start to saturate the cpu.  the
nice value will have a tendency to lock out the database process.
THAT IS, THE EFFECT OF NICE IS STATE DEPENDENT.  on lightly
loaded systems, the recent cpu used will dominate in differentiating
between processes.  on heavily loaded systems, the nice value
will tend to dominate (because of the fast rate at which the recent
cpu measure is decayed).

danny chen
att!homxc!dwc