Hi--
On Oct 14, 2009, at 1:35 PM, PGNet Dev wrote:
On Wed, Oct 14, 2009 at 12:09 PM, Chuck Swiger <[email protected]>
wrote:
Yes, your local time is too far off from the time from the NTP
timesources
you have configured, and ntpd probably can't sync time to them
(hence the
"sync_alarm" in status), so it's not updating the values in the
line you
point out. Stop ntpd, run "ntpdate -b" twice against some
timeserver-- once
to correct your clock, once to confirm that the time has been reset
properly, so should have a minimal correction-- and then restart
ntpd.
I've done that repeatedly. Well, actually, using,
sntp -V -P no -r clock.fmt.he.net
instead of ntpdate, but the effect's the same -- stop ntpd, manually
set & check the time, then start ntpd.
I'm less familiar with sntp, but the man page suggests you're using
sensible options.
What is the output, from running it? From a machine with a clock
which is in sync, I get:
# sntp -V -P no -r clock.fmt.he.ne
sntp options: a=2 v=2 e=0.100 E=5.000 P=2147483647.000
d=15 c=5 x=0 op=1 l=/etc/sntp.pid f= clock.fmt.he.net
sntp: offset=-0.003+/-0.011 disp=0.000
sntp: correction -0.003 +/- 0.000+0.011 secs - ignored
"sometimes" it'll cause an immediate Stratum2 sync, with 377 reach in
5-10 mins. other times, same config, it'll never get out of Stratum
16. something's seriously horked on this sytem -- i just can't figure
out what.
If you wait an hour, or a day, without running ntpd, and try to re-run
the sntp command again, what is the offset you are seeing?
If your clock is drifting by more than about a minute per day (I think
the actual value is 43 seconds), your hardware clock is too broken to
be able to sync with real time short of extreme measures. You might
be better off not running ntpd at all in such case, and just run sntp
via cron every hour.
However, you should also review the maxpoll settings you are using
and which
NTP timeservers you are using, because you should not be polling
stratum-1
servers every minute.
at the moment, i've,
cat /etc/ntp.conf
server clock.fmt.he.net iburst
server clock.isc.org iburst
server clock.sjc.he.net iburst
server t1.timegps.net iburst
server nist1.aol-ca.truetime.com iburst
driftfile /var/lib/ntp/drift/ntp.drift
if i do NOT specify servers near me, and/or go so far as to actually
use *pool.ntp.org, the jitters rise dramatically ... and stay high.
i'm more than happy to change the config -- i frankly don't care WHAT
servers i use, as long as i can get stable time that'll stop killing
off local servers ...
Right, OK-- from your earlier mail, you mentioned something about
running with Xen Dom0/DomU. There is absolutely no point to running
ntpd in a guest domain-- you should only try to run ntpd in a normal
OS, or, as a last resort, in the Dom0 domain. The other domains can
and should simply use the HW clock, because latencies and such for the
guest domains are highly unpredictable. There may be a sysctl or
Linux /proc thingy called xen.independent_wallclock which can be
toggled.
Regards,
--
-Chuck
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
