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. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
