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

Jim Houston jim.houston at ccur.com
Tue Sep 9 02:27:24 UTC 2008


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