hi,

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.

"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.

> 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 ...
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers

Reply via email to