[ntp:hackers] odd behaviour (one more time)

David L. Mills mills at udel.edu
Tue Sep 9 15:15:35 UTC 2008


The behavior reported, in particular the decaying transient, is very 
characteristic of underdamped transient response, which would be 
expected if the time constant was not matched to the sampling rate. This 
is a known problem with Linux tick intervals other than 10 ms. There is 
a good deal of intricate engineering and mathematical models involved so 
that a simple change of poll interval hooks up with all the other 
parameters to insure consistent damping throughout the range of poll 

The reported transients do not happen in systems other than Linux. If 
the problem reported is specific to Linux, I can offer no help other 
than for the Linux folks to study the mathematics in rfc1305 and my 
book. I do know the linux kernel applique does not completely adhere to 
the microkernel implementation in Solaris or the nanokernel 
implemenation in FreeBSD. However, the differences I do know about 
should have no influence on the transfer function. Accordingly, if some 
recent Linux adaptation has broken the nanokernel parameters, somebody 
else should look into it.


Jim Houston wrote:

> On Monday 08 September 2008 17:47:05 Reg Clemens wrote:
>>> On Monday 08 September 2008 13:55:46 you wrote:
>>>>> Reg,
>>>> <http://www.swcp.com:/~reg/offset.jpg>
>>> Hi Reg,
>>> I would suspect that the problem is with the time_constant
>>> value which the kernel is using.
>> You mention the kernel, but this is a strictly userland ntpd.
>> Linux does not have the kernel implementation of ntp (yet).
>>> You might use ntp_time
>>> to check the time_constant value. In particular how does
>>> this value compare between a broken and working versions
>>> of ntpd?
>>> I'm replying privately because I'm speculating and don't
>>> want to waste everyones time if I'm wrong. I think there
>>> was a flag day style change in the interpretation of the
>>> time constant value. I expect you will see time constant
>>> values that differ by 4.
>> Well, I think you are on to something there.
>> I'm not sure exactly what you are saying, but your observation
>> is definitely right.
>> On the 'working' ntpd, which is p115, I see time constant of 4
>> with ntptime.
>> With the ntpd that gives the oscillations (p127) I saw
>> a time constant of 2 when it first started, then it dropped to 0,
>> so there is your difference of 4.
>> At the moment p127 has only been running a few minutes, but
>> the clock offset is on its way up. It started at about 5us, went
>> up to about 50us, and has dropped a bit, but holding in that area.
>> Incidentally, I have only seen the large oscillations that one time,
>> so it almost seems that something is unstable, and needs to be
>> kicked 'just right' to oscillate.
>> Could you explain the 'change by 4' ???
>> If you like, please post your comments on line and I will respond,
>> or you can include any of this message with your posting.
> Hi Reg, David, Everyone,
> First the reference to the kernel is correct. The adjtimex system
> call in linux implements the ntp PLL/FLL logic. One of the values
> passed into the kernel with this system call is the time_constant
> value. This controls how quickly the kernel adjusts the system
> time in response to the offset values which are also passed into
> the kernel with adjimex.
> I'm not going back to check the details but here is my understanding
> of the history of the time_constant value. When the option of passing
> adjtime offsets in nanoseconds was added to nptd the meaning of the
> time_constant value changed.
> If you look in ntpd/ntp_loopfilter.c you will find some code like this:
> #ifdef STA_NANO
> ntv.constant = sys_poll;
> #else
> ntv.constant = sys_poll - 4;
> #endif
> In previous versions of ntpd there was logic which checked if the
> kernel supported the nanosecond interface rather than this
> compile time check. Last I checked the STA_NANO support going
> into kernel.org has a dynamic check which tries to do the right
> thing to work with ntpd compiled with or without STA_NANO.
> I hope this helps.
> Jim Houston - Concurrent Computer Corp.

More information about the hackers mailing list