[ntp:hackers] ntp p110 and setting frequency and offset still off.
David L. Mills
mills at udel.edu
Thu Feb 7 03:22:28 UTC 2008
Brian,
Look at line 789 in kern.c of the microkernel. See the several terms to
the right of the >> operator. They all must be in log2 scaling. Now look
at SHIFT_KF in Solaris timex.h. Ooop.
It is possible that line could be refomulated to use muliplies rather
than shifts, but I sure would be concerned about overflow and/or loss of
precision.
Dave
Dave
Brian Utterback wrote:
> I continue to be confused. Looking at the microkernel reference code
> and the kernel code in Solaris, it
> is apparent that the calculated frequency is directly related to the
> delta time as defined by the current
> time minus the reftime. So, I don't see how any attempt to measure
> the frequency change can be valid
> without taking into account the time since the last offset set.
>
> When I start up ntpd p111, with the ntp.drift file set and an offset
> of 100ms, the offset is cleared to
> zero and then the frequency is set to the value in the ntp.drift file,
> both within 5 seconds of startup.
> Since I am using iburst mode, about 12 seconds after start up, the
> offset is set to -99.x.
> Then a few minutes later, the offset is set to something between -80
> and -99. And
> then once more a couple of minutes later the offset is set to
> something between -40 and
> -70. By this point the offset is radically incorrect, but it seems to
> me that this makes sense,
> since the time between each offset was enough to amortize the offset,
> so the kernel
> would assume that those next two offsets are drifts that have occurred
> in just those
> few minutes between offsets.
>
> So, again, I ask for confirmation that this is the expected behavior?
>
> David L. Mills wrote:
>
>> Brian,
>>
>> I found at least one bogeyman. I also found a simpler way to measure
>> the open-loop rsponse.
>>
>> Starting from a runnning client system close to server time and
>> frequency, stop the daemon and edit the configuration file to put
>>
>> disable ntp
>> server <old server> maxpoll 6 noselect
>>
>> Start the daemon and be sure the loopstats is enabled. Then, run
>>
>> ntptime -t 2 -s 1
>>
>> followed by
>>
>> ntptime -o 100000
>>
>> That puts in the inital step. You can track time offset behavior in
>> the loopstats or ntptime program. On my Blade the frequency change is
>> 111 PPM (!!) and the timeoffset starts going negative to the general
>> depth of the Mariannas Trench. On a FreeBSD nanokernel the inital
>> frquency change is about 0.5 PPM.
>>
>> Claarly, something is broken in the hardupdate() routine where the
>> frequency is updated. look for the ltemp *= mtemp; line and work from
>> there. That SHIFT_KF - SHIFT_USEC looks mighty suspicious when
>> comparing Solaris timex.h and that code. Probably the best thing is
>> to rip out the multiplies and put the shifts back in.
>>
>> The misbehavior between the Ultra and Blade could be an overflow
>> problem. I think everything here is 64-bit, but am not sure.
>>
>> Dave
>> > snip
>>
>
>
More information about the hackers
mailing list