[ntp:questions] Re: Problem Disabling Local Time Synch

David L. Mills mills at udel.edu
Fri Feb 4 04:03:52 UTC 2005


Tom,

Reset. You have tripped over one of the things that ignited the 
transition to NTPv4. Not only is the "Previous..." comment superflous, 
it reveals that xntpd had a seriously defective clock discipline. The 
first one is that the remaining adjustment after adjtime() completes 
should NOT be included in the following update. So says the math and so 
says the engineering analysis. Second is that xntpd operates on 
misleading timescales. There is a timescale for applications and another 
for xntpd itself and they can differ by a modest fraction of a second.

It generally causes no harm if ntpd (or xntpd) operate at other than the 
highest priority. It does matter if the system misses timer interrupts. 
It surely minds if something else is torqueing the clock and xntpd (or 
ntpd) is not told to bug off. I don't remember a way to turn off the 
clock discipline entirely in xntpd. You can do that in ntpd with the 
command "disable ntp" in the configuration file.

A better way to implement a server where the time is controlled by 
another device is usint the configuration designed for the NIST servers 
using a special ACTS scheme called lockclock. This should work with any 
configuration where something other than ntpd disciplines the system 
clock. Define LOCKCLOCK in the conf.h configuration file before 
configuring and compiling the system. Use (only) the local clock driver. 
Configure your other primary server in the configuration file, but set 
the noselect keyword in the server line. This way you can watch each 
server from the other for management purposes.

Be advised there has been little testing with the LOCKCLOCK 
configuration, so it should be considered alpha.

Dave

Tom Einertson wrote:

> We have a system here consisting of a number of computers, two of which
> are time sources, and the others which are time clients.  On the time
> masters we have a serial connection to a satellite time receiver, and
> we have a program that acquires this time from the satellite and synchs
> that server's time to the satellite.  We run xntpd on the time servers
> to distribute time to the clients.  The problem is that we keep getting
> the following message in the console logs on our time masters.
> 
> xntpd[7770]: Previous time adjustment didn't complete
> 
> A little research indicated that this error means that one adjtime call
> didn't complete before the next one was made, and that this can be
> caused if NTP doesn't run at a high enough priority, or if there is
> another time synch program running on the same server.  I didn't think
> that NTP was having trouble being scheduled on this system, but then I
> realized that I hadn't told NTP not to try to synch the time on this
> server, so it was probably fighting with our other time synch program.
> I then added 'disable pll' to the NTP config file, figuring this would
> stop NTP from trying to synch the time and I restarted NTP.  I figured
> that if NTP wasn't trying to adjust the local clock, it wouldn't be
> calling adjtime, and it wouldn't be generating this error any more.
> This didn't seem to make any difference, so there must be something
> that I don't understand about this.  Any idea what it might be?
> 
> In case it matters, this system runs AIX 4.3.3, and the NTP version is
> 3.4y.  Here is a copy of the NTP config file from that system.
> 
> broadcastclient
> driftfile /etc/ntp.drift
> tracefile /etc/ntp.trace
> #
> server 127.127.1.1             # LCL, local clock
> fudge  127.127.1.1 stratum 12  # increase stratum
> disable pll
> 
> Any idea what I'm doing wrong here?
> 
> PS - I know we should have more than two time servers here - I'm
> working on that.
> 
> -- 
> Tom Einertson                              E-mail: tome at siemens-emis.com
> SIEMENS Power Transmission & Distribution  Phone:  (952) 607-2244
> Energy Management & Automation Division    Fax:    (952) 607-2018
> 10900 Wayzata Boulevard, Suite 400
> Minnetonka, MN, 55305



More information about the questions mailing list