Date: Thu, 2 Mar 2000 16:17:15 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Matthew D. Fuller" <fullermd@futuresouth.com> Cc: Wes Morgan <morganw@engr.sc.edu>, Ollivier Robert <roberto@keltia.freenix.fr>, freebsd-current@FreeBSD.ORG Subject: Re: ntpd hanging machine Message-ID: <200003030017.QAA04060@apollo.backplane.com> References: <Pine.BSF.4.21.0003021658340.1099-100000@volatile.by-tor.tacorp.net> <200003022255.OAA03429@apollo.backplane.com> <20000302173158.B18770@futuresouth.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:On Thu, Mar 02, 2000 at 02:55:16PM -0800, a little birdie told me
:that Matthew Dillon remarked
:>
:> rtprio (and idprio) is virtually guarenteed to lockup your machine
:> eventually. Don't use either.
:
:Hm.
:I've run ntpd rtprio'd to 52 for over a year, under -CURRENT and
:RELENG_2_2. Never had a freeze/crash I coudl attribute to it.
:
:--
:Matthew Fuller (MF4839) | fullermd@over-yonder.net
idprio is a bigger problem then rtprio, but both suffer from
priority inversion issues. If an idprio process blocks on something
(like a disk read) and a normal process gets into a cpu-bound loop,
the idprio process never gets cpu and the result is that all the
resources locked by the idprio process while it is blocked stay locked.
This can lockup the kernel.
An rtprio process, being higher priority, has a similar issue but in
a reverse sense. If a normal process blocks on something like a disk
read and an rtprio process gets stuck in a cpu-bound loop, another rtprio
process trying to do something that requires the resources locked by the
non-rtprio process will block indefinitely.
idprio based priority inversion problems are a bigger issue since it
is far more likely for a normal process to get stuck in a cpu-bound
loop.
I run my ntpd's normally. I don't use rtprio or idprio. It works just
fine, even on systems with heavy loads. If you are worried you can run
it at nice -20 (still as a normal process). The reason it will work just
fine is simply because it does not use very much cpu so when it *does*
need the cpu the scheduler gives it cpu. The ntp protocol takes into
account laggy networks and laggy response times, all you loose is a few
milliseconds in accuracy (big whoopteedo).
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003030017.QAA04060>