On Mon, Dec 10, 2007 at 04:07:17PM -0500, 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.

>

> So, these are the same boxes and only the OS was changed, that's why I am

> asking.

Some archs use timecounter code now for the clock. That code has a lot

of benefits, but the range of clock drifts that can be compensated for

is not very big. I have an experimental diff here that might solve

your case. See below.
> One example of sampling, where th gap keep getting bigger:

quoted text
> Dec 10 15:07:46 ntp1a ntpd[28571]: adjusting local clock by 0.589365s

> Dec 10 15:10:25 ntp1a ntpd[28571]: adjusting local clock by 0.619122s

> Dec 10 15:10:57 ntp1a ntpd[28571]: adjusting local clock by 0.625311s

> Dec 10 15:13:09 ntp1a ntpd[28571]: adjusting local clock by 0.654803s

> Dec 10 15:15:53 ntp1a ntpd[28571]: adjusting local clock by 0.665832s

> Dec 10 15:18:26 ntp1a ntpd[28571]: adjusting local clock by 0.755500s

> Dec 10 15:22:48 ntp1a ntpd[28571]: adjusting local clock by 0.777401s

> Dec 10 15:25:27 ntp1a ntpd[28571]: adjusting local clock by 0.786259s

> Dec 10 15:28:41 ntp1a ntpd[28571]: adjusting local clock by 0.855696s

> Dec 10 15:31:21 ntp1a ntpd[28571]: adjusting local clock by 0.901818s

> Dec 10 15:34:34 ntp1a ntpd[28571]: adjusting local clock by 0.986841s

> Dec 10 15:38:48 ntp1a ntpd[28571]: adjusting local clock by 0.890534s

> Dec 10 15:39:19 ntp1a ntpd[28571]: adjusting local clock by 1.003113s

> Dec 10 15:43:35 ntp1a ntpd[28571]: adjusting local clock by 1.003807s

> Dec 10 15:44:09 ntp1a ntpd[28571]: adjusting local clock by 1.000521s

> Dec 10 15:46:17 ntp1a ntpd[28571]: adjusting local clock by 1.070674s

> Dec 10 15:50:29 ntp1a ntpd[28571]: adjusting local clock by 1.012753s

> Dec 10 15:54:40 ntp1a ntpd[28571]: adjusting local clock by 1.011539s

> Dec 10 15:56:52 ntp1a ntpd[28571]: adjusting local clock by 1.109486s

> Dec 10 16:00:05 ntp1a ntpd[28571]: adjusting local clock by 1.024082s

>

>

> 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?

I would really have to look into the code to see if it's feasible to

start adjusting frequency when not synced. Currently I do not think it

will work without some rewriting. I am also worried the complexity of

the code would increase, or some oscillating effect would be

introduced in some cases. 
>

quoted text
> 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?

Yes, you can create a drift file yourself and (re)start ntpd. For that

to work you'll need a reasnable estimate of the dirft.
So to summarize, you can do three things:
1. Test the diff below

2. Hack the ntpd code to start using adjfreq without being synced (not recommended)

3. Estimate the drift yousrelf and create a ntpd.drift file.
I would start with 1.
	-Otto
Index: kern_tc.c

===================================================================

RCS file: /cvs/src/sys/kern/kern_tc.c,v

retrieving revision 1.9

diff -u -p -r1.9 kern_tc.c

--- kern_tc.c	9 May 2007 17:42:19 -0000	1.9

+++ kern_tc.c	12 Nov 2007 20:07:17 -0000

@@ -567,11 +567,11 @@ ntp_update_second(int64_t *adjust, time_

 	if (adjtimedelta.tv_sec > 0)

 		adj.tv_usec = 5000;

 	else if (adjtimedelta.tv_sec == 0)

-		adj.tv_usec = MIN(500, adjtimedelta.tv_usec);

+		adj.tv_usec = MIN(5000, adjtimedelta.tv_usec);

 	else if (adjtimedelta.tv_sec < -1)

 		adj.tv_usec = -5000;

 	else if (adjtimedelta.tv_sec == -1)

-		adj.tv_usec = MAX(-500, adjtimedelta.tv_usec - 1000000);

+		adj.tv_usec = MAX(-5000, adjtimedelta.tv_usec - 1000000);

 	timersub(&adjtimedelta, &adj, &adjtimedelta);

 	*adjust = ((int64_t)adj.tv_usec * 1000) << 32;

 	*adjust += timecounter->tc_freq_adj;