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,

quoted text
>

> 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