Dave wrote:
> Looking at the logs on my Sun Blade 2000 running Solaris 10, I see
> numerous occasions on which the time has been stepped. Looking at the
> few only (today, 1/5/2008), I see it was stepped around +0.3 sec at 3
> AM, then -0.4 at 4:30 am, then half an hour later at 5am it was moved
> -0.6 sec, then 40 minutes later it is moved another -0.6 sec. Since then
> (its now 1:30 pm), it has not changed.
>
> Is this excessive? I cant believe the clock is that unstable. Its not in
> an air-condition room, but the machine has an uptime of a few weeks, so
> it must be reasonably temperature stable now.
>
> Apr 27 14:08:07 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) 0.228893 s
> Apr 28 06:35:55 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) 0.177999 s
> Apr 28 06:59:39 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) -0.338394 s
> Apr 28 21:22:22 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) -0.270417 s
> Apr 29 02:52:35 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) 0.250878 s
> Apr 29 07:09:23 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) 0.129417 s
> Apr 29 07:36:45 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) -0.331172 s
> Apr 29 21:08:29 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) 0.220048 s
> Apr 29 23:09:43 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) -0.261370 s
> Apr 30 00:00:50 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) -0.386788 s
> Apr 30 17:23:40 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) -0.188325 s
> May 1 03:01:27 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) 0.296458 s
> May 1 04:29:22 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) -0.444097 s
> May 1 05:00:18 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) -0.635503 s
> May 1 05:39:13 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) -0.665786 s
>
>
> My config file is below. I'm not sure if I would be better picking time
> servers close to me.

I am, and you would be! See below.
>
>
<snip>
> server navobs1.oar.net
> server utcnist.colorado.edu
> server gnomon.cc.columbia.edu
> server ntp.colby.edu
> server clepsydra.dec.com
> server chronos.cru.fr
> server ptbtime1.ptb.de
> server ntp.metas.ch
<snip>

You seem to have achieved extreme geographical diversity; IOW you are
using servers located all over the planet!

Servers that are closest to you, in net space; e.g. those with the
lowest value of delay are usually the best choices. Delay is important
because the maximum uncertainty in transmitting time from client to
server is less than or equal to one half of the round trip delay.

All of those servers should have a very good idea of what time it is!
By the time your request packet and the reply have been bounced all over
the planet, the uncertainty is too large for best performance.

Four servers are the minimum for a robust configuration. The magic
numbers are four, five, and seven; protecting you, respectively, from
the failure of one, two, or three servers. Note that "failure" includes
both not responding at all and responding with an incorrect time. It
may be worth noting that the last NTP Survey found several servers
responding to NTP queries without even knowing the correct year!!

I'd suggest picking four servers close to you in net space and running
with those. If you can find five servers close to you, there is no harm
in using all five.

If you feel you need seven, please consider setting up your own stratum
one server using a GPS timing receiver and making it available for
general use.