Date: Tue, 19 Jul 2005 08:48:19 -0400 From: "Joshua Coombs" <jcoombs@gwi.net> To: <freebsd-ppc@freebsd.org> Subject: Re: Minor issues of time on PPC Message-ID: <0cbd01c58c60$246dc590$1700a8c0@failure> References: <p0623094fbf02347491f0@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- From: "Garance A Drosihn" <drosih@rpi.edu> To: <freebsd-ppc@FreeBSD.org> Sent: Tuesday, July 19, 2005 1:02 AM Subject: Minor issues of time on PPC > I've noticed a few minor issues with tracking the present time > on my Mac-mini. <snip> > Hmm. I just noticed that > ntpd is running with '-f /var/db/ntpd.drift' -- but that file does > not exist. But then, it doesn't exist on my other freebsd machines, > and they all seem to keep accurate time. Still, I'm going to try > creating that file and see if it does any good. echo 0 > /var/db/ntpd.drift restart ntpd ntpd can be pissy at times if it only has 1 or 2 external servers to work with. It'll decide that the local system is infact more accurate and start ignoring remote systems, drifting further and further as the system runs. Easiest way to prevent this, have more than 2 servers listed. example /etc/ntp.conf: server 0.pool.ntp.org iburst server 1.pool.ntp.org iburst server 2.pool.ntp.org iburst server 127.127.1.1 fudge 127.127.1.1 stratum 12 driftfile /var/db/ntp.drift This conf pulls 3 servers from the public ntp pool project, and sets up a 'local' refrence clock to fall back to should all three remote servers go down. This is just the local clock after being disciplined by ntp, so it's not accurate, hence the very high stratum forced on it. 'iburst' tells ntp to be aggressive figuring out drift and jitter at startup to get the local clock disciplined quickly. Lastly we define the drift file in the conf so you don't have to specify it on the command line. example /etc/rc.conf settings: ntpdate_enable="YES" ntpdate_flags="-g -q -N high" ntpdate_program="/usr/sbin/ntpd" xntpd_enable="YES" xntpd_flags="-g -p /var/run/ntpd.pid" This sets up a couple things. First, ntpdate is depreciated, so we use ntpd to set the initial time. This takes slightly longer but in addition to setting the time it puts an initial clock rate adjustment into place. Also, '-N high' tells ntpd to use a higher scheduling priority than normal. ntpd doesn't use much cpu, so when it does, I prefer to let it have as much as it needs uninterrupted. Try this, let the machine run for a couple hours, then email the output of: ntpdc -c loopinfo ntpdc -c kerninfo ntpq -p Based on that, we can see if ntp is at fault, or something else is up. <snip> > (other examples: > - locate doesn't seem to work at all, which I actually > have started to look into a bit. Does it complain there isn't a locate db? /usr/libexec/locate.updatedb to bring it up to date Joshua Coombs
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0cbd01c58c60$246dc590$1700a8c0>