I've seen this happen too but ended up just shutting off ntpd entirely
and croned an rdate in it's place.
In my case the clock goes WAAAAAAY out and even when I fix it it flys
way out on the next NTP interval.
Even if I restart NTPD the damned thing flies way out again a while
later.
I'm sure the clock is totally screwed on this machine but ntpd didn't
help _AT ALL_ just made things worse.
A cron'd rdate is keeping things in check now that I've turned off
ntpd (waiting to replace the hardware).
I was under the impression that ntpd should be keeping things straight
but it wasn't at all (hence turfing it).
One of this days I'll spend the time to figure out what ntpd actually
does. :P
Snippet from /var/log/daemon:
daemon:Nov 25 07:16:24 mail ntpd[3292]: reply from 209.139.209.82:
negative delay -0.021739s, next query 3211s
daemon:Nov 25 07:29:04 mail ntpd[3292]: reply from 209.139.208.96:
negative delay -0.026221s, next query 3000s
daemon:Nov 25 07:45:01 mail ntpd[3292]: reply from 204.174.89.240:
negative delay -0.000481s, next query 3273s
daemon:Nov 25 07:48:18 mail ntpd[1183]: adjusting local clock by
59320.679282s
daemon:Nov 25 08:10:02 mail ntpd[3292]: reply from 209.139.209.82:
negative delay -0.020042s, next query 3267s
daemon:Nov 25 08:19:04 mail ntpd[3292]: peer 209.139.208.96 now valid
daemon:Nov 25 08:39:34 mail ntpd[1183]: adjusting local clock by
59329.014887s
daemon:Nov 25 08:43:41 mail ntpd[1183]: adjusting local clock by
59319.361513s
daemon:Nov 25 08:45:46 mail ntpd[1183]: adjusting local clock by
59314.438839s
daemon:Nov 25 08:47:26 mail ntpd[1183]: adjusting local clock by
59310.402041s
daemon:Nov 25 08:51:13 mail ntpd[1183]: adjusting local clock by
59301.408815s
daemon:Nov 25 08:52:49 mail ntpd[1183]: adjusting local clock by
59297.653276s
daemon:Nov 25 08:57:01 mail ntpd[1183]: adjusting local clock by
59287.549873s
daemon:Nov 25 08:59:44 mail ntpd[1183]: adjusting local clock by
59281.201113s
daemon:Nov 25 09:01:18 mail ntpd[1183]: adjusting local clock by
59277.545620s
daemon:Nov 25 09:01:51 mail ntpd[1183]: adjusting local clock by
59276.293823s
daemon:Nov 25 09:04:29 mail ntpd[3292]: peer 209.139.209.82 now valid
daemon:Nov 25 09:05:03 mail ntpd[1183]: adjusting local clock by
59268.871698s
daemon:Nov 25 09:06:38 mail ntpd[1183]: adjusting local clock by
59265.077072s
daemon:Nov 25 09:10:59 mail ntpd[1183]: adjusting local clock by
59254.692520s
daemon:Nov 25 09:14:16 mail ntpd[1183]: adjusting local clock by
59247.127138s
daemon:Nov 25 09:18:01 mail ntpd[1183]: adjusting local clock by
59238.282543s
daemon:Nov 25 09:19:43 mail ntpd[1183]: adjusting local clock by
59234.406758s
daemon:Nov 25 09:23:33 mail ntpd[1183]: adjusting local clock by
59225.631214s
daemon:Nov 25 09:27:19 mail ntpd[1183]: adjusting local clock by
59216.849676s
daemon:Nov 25 09:30:24 mail ntpd[1183]: adjusting local clock by
59209.675600s
daemon:Nov 25 09:33:14 mail ntpd[1183]: adjusting local clock by
59203.072213s
daemon:Nov 25 09:35:53 mail ntpd[1183]: adjusting local clock by
59196.728028s
daemon:Nov 25 09:39:06 mail ntpd[1183]: adjusting local clock by
59189.182660s
daemon:Nov 25 09:42:55 mail ntpd[1183]: adjusting local clock by
59179.901572s
daemon:Nov 25 09:45:04 mail ntpd[1183]: adjusting local clock by
59174.749391s
daemon:Nov 25 09:48:18 mail ntpd[1183]: adjusting local clock by
59167.009772s
daemon:Nov 25 09:50:28 mail ntpd[1183]: adjusting local clock by
59161.774410s
daemon:Nov 25 09:54:15 mail ntpd[1183]: adjusting local clock by
59152.951333s
daemon:Nov 25 09:58:28 mail ntpd[1183]: adjusting local clock by
59142.836328s
daemon:Nov 25 10:00:36 mail ntpd[1183]: adjusting local clock by
59137.816565s
daemon:Nov 25 10:02:13 mail ntpd[1183]: adjusting local clock by
59133.771875s
daemon:Nov 25 10:06:33 mail ntpd[1183]: adjusting local clock by
59123.468998s
daemon:Nov 25 10:07:39 mail ntpd[1183]: adjusting local clock by
59120.812184s
daemon:Nov 25 10:10:07 mail ntpd[3292]: peer 69.77.167.215 now invalid
daemon:Nov 25 10:10:16 mail ntpd[1183]: adjusting local clock by
59114.600294s
daemon:Nov 25 10:13:02 mail ntpd[1183]: adjusting local clock by
59107.913735s
daemon:Nov 25 10:17:00 mail ntpd[3292]: peer 209.139.209.82 now invalid
On 10-Dec-07, at 3:07 PM, Daniel Ouellet wrote:
Hi,
Looking a the code, I am trying to understand something on some
servers that just don't stay sync in the latest kernel (current).
I see some changes were done to the drift, and a few other things.
What is really the logic in the daemon to actually send a sync
message and more importantly to write the /var/db/drift file to then
start to adjust the clock.
I am asking, because looks like some clock drift more then the
correction done to it.
I can see the clock get sync for may be 1 or 2 minutes only after
one to three hours trying and then continuing to try to catch up and
no drift file are written.
With the new/current code, is it possible to have a situation where
the drift is bigger then what's needed in difference between
sampling to get the clock to sync and write the drift file and then
start to adjust the clock to stay more in sync?
Hoe my explications make sense as I have a few Sun servers that were
keeping time no problem before with 4.1, but then running 4.2
current, they can't get and stay in sync now.
My understanding of the man page is that drift file will be written
only after the clock is in sync and then adjfreq will kick in to
adjust it and keep the time in sync better. But what about if it
can't sync, or stay in sync to have time to write the drift file,
what then?
Wouldn't it make sense to be able to compensate for that and may be
have ajdfreq start to play in to help address cases like this?
I see some code have changes for this to reset the adjfreq 2 weeks
and 4 days ago.
Anyway, can it be force to start using adjfreq somehow before it is
in sync if only for testing reason?
Best,
Daniel
