[ntp:questions] Re: Problem Disabling Local Time Synch
David L. Mills
mills at udel.edu
Fri Feb 4 04:03:52 UTC 2005
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.
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: 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.
> 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