[ntp:hackers] ntp p110 and setting frequency and offset still off.

Brian Utterback brian.utterback at sun.com
Fri Feb 1 14:53:14 UTC 2008


More info:


12 hours later and the frequency still isn't close.

I get a similar problem with starting ntpd-p110 with a drift file.
The frequency gets set okay, then a few seconds later an offset.
After the next offset, the frequency gets driven down and then
takes quite a while to get back up.

On the other hand, if I wait until after the offset is set and
the frequency is driven down and then use ntptime to set the
frequency back to the correct value, it is totally stable and
the offset stay small and the frequency stays within 1 PPM.

I think this suggests that anytime the frequency is directly
set, the offset must be set immediately before that. However,
this pre-supposes that the offset is recalculated from that
point onward.

This brings up a point that has bothered me a bit. As far
as I know, when we have the 8 samples and we use one, after
that point we only use newer samples. But, if we select a
sample, and then that offset is fed into the kernel, doesn't
that invalidate all of the samples? Certainly all previously
collected offset values need to be adjusted by the offset
that went into the kernel. But I don't see that anywhere
in the code. Is that what is happening, or am I misunderstanding
something?

Brian Utterback wrote:
> One of the changes that went into p110 that I was waiting for
> was that Dave split the setting of the frequency and offset with
> ntp_adjtime the first time the frequency is calculated. This was
> because of a bug in the original microkernel code that still existed
> in Solaris that meant that the frequency actually got set to about
> double the correct value when both the offset and frequency got
> set together. (by the way, this is now fixed in the Solaris Nevada
> development kernel) By splitting the two steps, the correct value
> gets set whether or not the bug is in the kernel.
> 
> All well and good, but my observation is that they got a little too
> far split. My tests had this happen:
> 
> time
> 0     set freq, offset, maxerror, esterror, time-const = 0, status=1
> 7s    set off=23us, + initial values maxerr, esterr, and time const=2
> 329s  set freq -28638  (this is almost exactly the measured value
>            should be. Yah!)
> 329s  set offset=0 (wha?)
> 393s  set offset -24069us (this offset then causes the frequency to
>            get recalculated to -30176)
>  From that point until 1179s, the offset's magnitude grows until
> it hits -40241, and then it starts back down, but by then the time
> constant is 3 and continues to grow, so the trip back takes much
> longer. At 2110s, the frequency is still at -36749 and the time
> constant is up to 4.
> 
> It seems to me that there should have been an offset value given
> at pretty much the same time as the frequency was set. Am I wrong?

-- 
blu

"Mr. Jefferson, build up that wall!"
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom


More information about the hackers mailing list