Date: Mon, 09 Sep 2019 15:16:52 -0600 From: Ian Lepore <ian@freebsd.org> To: Cy Schubert <Cy.Schubert@cschubert.com>, Konstantin Belousov <kostikbel@gmail.com> Cc: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, Harlan Stenn <stenn@nwtime.org>, Vladimir Zakharov <zakharov.vv@gmail.com>, freebsd-current@freebsd.org Subject: Re: ntpd segfaults on start Message-ID: <b4051fd6d6f50dabaaff7dfefb5d47148811126a.camel@freebsd.org> In-Reply-To: <201909091928.x89JSZMm062482@slippy.cwsent.com> References: <201909091630.x89GUjGX044288@gndrsh.dnsmgr.net> <ef8b67577e6512313261693cbbf40e24f007b6c4.camel@freebsd.org> <20190909184446.GU2559@kib.kiev.ua> <201909091928.x89JSZMm062482@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2019-09-09 at 12:28 -0700, Cy Schubert wrote: > > > > On the other hand, the code execution times are not predictable if the > > process's pages can be paged out. Under severe load next instruction > > might take several seconds or even minutes to start. It is quite unlike > > the scheduler delays. That introduces a jitter in the local time > > measurements and their usage as done in userspace. Wouldn't this affect > > the accuracy ? > > IMO it would and would be unacceptable when used as a stratum N server or > with some OLTP or database applications. Locking a few megabytes is a small > cost. What I proposed was changing the default to not lock all of ntpd into memory, because I think that would work well for most users. Admins running stratum 1 or 2 servers are probably a bit more savvy about ntp configuration than the average user, and would use the rlimit command in ntp.conf. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b4051fd6d6f50dabaaff7dfefb5d47148811126a.camel>