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

David L. Mills mills at udel.edu
Sat Feb 2 04:37:29 UTC 2008


Brian,

With the frequency file set correctly and the initial server offset 
moderately large, does theloop behave as you expect? There is nothing 
special about the design here but live and die by the PLL and its time 
constant. You did mention the time constant does go up as time goes on; 
if it gets near to the max, your behavior is expected. This is not an 
issue for initial training.

The adaptive parameter behavior of the discipline is easily the most 
delicate algorithm in the collection. It is a compromise between rapid 
response and accurate response. Over the years a number of algorithms 
have been tried and evalutated. There might be ways it could be 
improved, but not without testing in the same range of conditions the 
current one is expected to survive. If you really do value quick 
convergence, set maxpoll to something smaller.

Just to touch all bases, have you confirmed the same behavior with both 
the daemon and kernel loops?



Dave

Brian Utterback wrote:

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



More information about the hackers mailing list