On Sat, 10 Jun 2000, Volodymyr Kostyrko wrote:

> On Fri, Jun 09, 2000 at 08:28:06PM -0400, Brian Fundakowski Feldman wrote:
> >    It's an issue. Nice values count for less than before due to fixes
> > that Luoqi Chen made (and I committed). The behavior now isn't optimal,
> > but it is better than the system locking up. NICE_WEIGHT might be okay
> > to keep at 2. Try the attached diff; I'm pretty sure it won't blow
> > things up :)
> >    The diff should make a process at -20 which uses all available CPU
> > schedule just slightly the ahead of a process at +20 which uses no CPU.
> > A process which uses full CPU at 0 niceness would have a priority of
> > 128, whereas a process using no CPU at 0 niceness would have a priority
> > of 90. All processes will always have a priority less than or equal to
> > 128, which is the priority at which a process with a niceness of +20
> > always runs at. A +20 process won't get better priority than anything
> > else, period. Try it out, see how it works for you:)
>   I think this is not the clear solution for descibed problem 'couse the dnetc 
>client still gets a priority and still have the share of time while other programs 
>might run. For me idprio works great. Just change last string in the starting shell 

There is no clear solution at all... try it out. Of _course_ it still gets a
share of the time.  If it didn't, then it could deadlock the system (like
idprio and rtprio both can).

>   idprio 31 su nobody -c "$dir/dnetc -quiet" 2>/dev/null >/dev/null &
> -- 
> [WBR], Arcade Zardos. [AIST] [SAT Astronomy//Think to survive!] [mp3.aist.net]

 Brian Fundakowski Feldman           \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]                    `------------------------------'

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to