Minor issues of time on PPC

[Joshua Coombs]

----- Original Message ----- 
From: "Garance A Drosihn" <drosih at rpi.edu>
To: <freebsd-ppc at 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