[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