[ntp:questions] Re: Solairs 8 xntpd client oscillates

Brian Utterback brian.utterback at sun.removeme.com
Tue May 9 17:33:36 UTC 2006


Richard B. Gilbert wrote:
> Joachim Schrod wrote:
>> Richard B. Gilbert wrote:
>>
>>>
>>> Sun's xntpd is about ten years behind the times.  Download the 
>>> current production version of the NTP distribution from 
>>> http://ntp.isc.org/bin/view/Main/SoftwareDownloads
>>
>>
>> I tried to avoid that because it would place ntpd outside the normal 
>> patch process. Therefore I googled before I posted and checked if I 
>> could find known problems with Sun's xntpd. I didn't found any 
>> mentioning of an oscillation problem.
>>
>> It was just mentioned that Solaris 8 always slews the clock and 
>> "disable pll" was recommended. (That did not help, as mentioned.) As 
>> far as I understand, the behaviour at my system might be due to a too 
>> large frequency error. Would the update to a current ntp version 
>> really help in that case?
>>
>> Cheers,
>>     Joachim
>>
> 
> Upgrading to the current version of ntpd might not solve your problem. 
> OTOH, we can't really support Sun's ten year old software here.
> 
> I would suggest that you download the current version, build it, and 
> install it in /opt/local.  That will leave Suns version intact and, in 
> the unlikely event that Sun issues a patch for their version, you will 
> be able to apply it with no difficulty.  Copy /etc/init.d/xntpd to 
> /etc/init.d/xntpd.original and then edt /etc/init.d/xntpd to use the 
> version in /opt/local.
> 
> Alternatively, you could ask Sun for support (and pay for it).
> 

Well, lets not go that far 8-). As we have stated in this forum
in the past, all support here is best effort, and some of us are
welling to expend that effort in directions that others are not.

That having been said, lets look at what we have got. It doesn't appear
to me that the offset is decreasing. The first 3 versions of the
patch 109667 set slewalways unconditionally, so if you have any of
these, then you do indeed need to set "disable pll".

Let me explain what the disable pll does and why you need it.

Many customers complained about the step behavior of xntpd. So, xntpd
was built with the already existing symbol "SLEWALWAYS" defined. This
forced xntpd to use a slew process instead of a step. This is the 
situation with these first three revs of the patch for Solaris 8.

The problem with SLEWALWAYS, is that it can take a very long time for
the clock to slew to the correct time. This presents a bit of a
conflict. The xntpd daemon cannot correct the clock, so it is known to 
have an incorrect time, although it is known what the offset from true 
time is. So, when a client asks the daemon for the time, what should it 
say? Does it respond with current system clock, which is known to be
wrong and may be so for quite a while into the future, or should it
respond with the system clock adjusted by the known offset?

So, xntpd had some clever code in it, modifying all the timestamps by
the known offset. Meanwhile, xntpd would slowly adjust the clock, using
the adjtime system call, which slews the clock. However, the higher
level of the code didn't know this, it was all implemented in the
lower levels. The xntpd daemon would call the routine that was supposed
to step the clock, and down in the guts, it was changed into an adjtime
call. The daemon would call the "get current time" routine, and in the
guts, the clock value read would be adjusted by the know offset. At the
higher logic levels, nothing was different.

The problem came when the offset become very small. The clock step logic
had code to clear the known offset once the clock step was 0. But the
bug is that once the clock offset gets very small, xntpd no longer
tries to set the clock itself, it instead uses the ntp_adjtime call to
slew the clock the last little bit. This part of the code knows nothing
about the known offset, so it does not get cleared. The problem is that
now xntpd thinks that there is no offset, but all of the timestamps read
have the last offset value added to them. It will thus adjust the clock
so that the calculated clock offset between the local system and it own
NTP server is 0. But since the clock has this offset added in, the clock
really ends up the offset value off of the real time and will stay
there permanently.

The easiest way to avoid this, is to not use the ntp_adjtime loop at 
all. This will force xntpd to use the routine that handles adjtime,
which does have the code to zero out the offset once the correction is
completed. This is exactly what "disable pll" does, it says to use
the adjtime call instead of the ntp_adjtime call.

Later, when other customers complained that it took too long to correct
the clock, the slewalways feature was made configurable at runtime.
Hence the commendation that you configure "disable pll" any time
you use "slewalways".

So, yes, when "disable pll" is used, the clock is adjusted. But the
ntp_adjtime call is better suited to keeping the clock in sync, so
it is better to not use "disable pll" unless you have to, i.e. when
using slewalways.

The man page is in error; it was copied from the html documentation
that came with xntpd when it was first ported to Solaris. Using
"disable pll" does not stop xntpd from updating the clock.





-- 
blu

Rose are #FF0000, Violets are #0000FF. All my base are belong to you.
----------------------------------------------------------------------
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom




More information about the questions mailing list