[ntp:questions] Re: ntpd Not Converging

Richard B. Gilbert rgilbert88 at comcast.net
Fri Nov 4 16:39:00 UTC 2005


David T. Ashley wrote:

>I am a first-time ntpd user.
>
>I have a Dell server running Red Hat Enterprise Linux.  If I reboot it, the
>real-time clock typically gains about 500ms.  Sometimes, if I'm testing
>something, I may reboot a few times and get the clock 1,500 or 2,000 ms
>ahead of true time.
>
>I don't want step jumps in my system, so I've added
>   tinker step 900.0
>to the config file.
>
>The server is fine as far as nominal clock frequency.  It is about 18PPM
>(maybe 10 seconds a week) slow.  The hardware clock is very much within
>ntpd's tolerance.
>
>If I run ntpd with no /var/lib/ntp/drift file, it establishes a drift
>correction in the direction of the post-reboot time error, and within a day
>or so it converges the kernel's clock onto true time.  The performance is
>fine.
>
>However, if I allow ntpd to load the /var/lib/ntp/drift file when it starts
>(this file is typically about 18.0), then it never seems to converge.  The
>behavior is that it recognizes that the offsets on the reference servers are
>a couple thousand milliseconds, but it leaves the kernel clock frequency to
>be consistent with /var/lib/ntp/drift ... forever.  I don't see any
>correction to get the server's time to line up with the time held by the
>time servers.  It will stay in a state of constant error.  Forever.
>
>Any ideas?
>
>My configuration file is pasted in below, as well as typical output from
>ntpq.  It stays in constant error forever.
>
>Thanks, Dave Ashley.
>
>----------
>
># Permit time synchronization with our time source, but do not
># permit the source to query or modify the service on this system.
>restrict default nomodify notrap noquery nopeer
>
>
># Permit some access over the loopback interface, at least
># enough to use the ntpq command.
>restrict 127.0.0.1 nomodify notrap nopeer
>
>
># -- CLIENT NETWORK -------
># Permit systems on this network to synchronize with this
># time service.  Do not permit those systems to modify the
># configuration of this service.  Also, do not use those
># systems as peers for synchronization.
># restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
>
>
># --- OUR TIMESERVERS -----
># minpoll  8 : Polling no more often than 4.2 minutes.
># maxpoll 13 : Polling no less often than every 2.3 hours.
>#
>server ntp-1.ece.cmu.edu               maxpoll 12
>server ntp0.cornell.edu                maxpoll 12
>server time-a.nist.gov                 maxpoll 12
>server time-b.nist.gov                 maxpoll 12
>server clock.psu.edu                   maxpoll 12
>server time-c.timefreq.bldrdoc.gov     maxpoll 12
>server utcnist.colorado.edu            maxpoll 12
>server ntp0.fau.de                     maxpoll 12
>server time.xmission.com               maxpoll 12
>server utcnist.colorado.edu            maxpoll 12
>server timekeeper.isi.edu              maxpoll 12
>
>
># --- NTP MULTICASTCLIENT ---
>#multicastclient                        # listen on default 224.0.1.1
># restrict 224.0.1.1 mask 255.255.255.255 nomodify notrap
># restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
>
>
># --- GENERAL CONFIGURATION ---
>#
># Undisciplined Local Clock. This is a fake driver intended for backup
># and when no outside source of synchronized time is available. The
># default stratum is usually 3, but in this case we elect to use stratum
># 0. Since the server line does not have the prefer keyword, this driver
># is never used for synchronization, unless no other other
># synchronization source is available. In case the local host is
># controlled by some external source, such as an external oscillator or
># another protocol, the prefer keyword would cause the local host to
># disregard all other synchronization sources, unless the kernel
># modifications are in use and declare an unsynchronized condition.
>#
>server  127.127.1.0     # local clock
>fudge   127.127.1.0 stratum 10
>
>
>#
># Drift file.  Put this in a directory which the daemon can write to.
># No symbolic links allowed, either, since the daemon updates the file
># by creating a temporary in the same directory and then rename()'ing
># it to the file.
>#
>driftfile /var/lib/ntp/drift
>broadcastdelay  0.008
>
>
>#
># Keys file.  If you want to diddle your server at run time, make a
># keys file (mode 600 for sure) and define the key number to be
># used for making requests.
>#
># PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote
># systems might be able to reset your clock at will. Note also that
># ntpd is started with a -A flag, disabling authentication, that
># will have to be removed as well.
>#
>keys            /etc/ntp/keys
>
>
># Don't ever correct by step jumping.  Slew always.  The value of 900
>seconds (15 minutes)
># is adequate to prevent step jumps unless something is really out of whack.
>#
>tinker step 900.0
>
># End of NTP.CONF.
>
>----------
>
>     remote           refid      st t when poll reach   delay   offset
>jitter
>============================================================================
>==
>+FS1.ECE.CMU.EDU 128.252.19.1     2 u    9   64  377   60.154  -1966.2
>3.880
>-cudns.cit.corne 192.5.41.209     2 u    2   64  377   36.935  -1959.4
>2.960
>+time-a.nist.gov .ACTS.           1 u   12   64  377   40.045  -1969.9
>6.622
>*time-b.nist.gov .ACTS.           1 u   10   64  377   40.004  -1970.6
>5.999
>-otc2.psu.edu    128.118.25.5     2 u    7   64  377   63.281  -1978.2
>11.805
>+time-C.timefreq .ACTS.           1 u   63   64  377   43.171  -1969.3
>3.302
> india.colorado. .INIT.          16 u    -  512    0    0.000    0.000
>4000.00
>+ntp0-rz.rrze.un .GPS.            1 u   64   64  377  139.034  -1966.1
>3.435
>+clock.xmission. .GPS.            1 u   63   64  377   60.140  -1968.6
>5.954
>+india.colorado. .ACTS.           1 u   14   64  377   42.651  -1967.3
>3.765
>-timekeeper.isi. .GPS.            1 u   60   64  377   90.197  -1954.3
>4.885
> LOCAL(0)        LOCAL(0)        10 l   59   64  377    0.000    0.000
>0.001
>
>
>
>  
>
What version of ntpd are you running? (ntpq -c version).

I'd suggest starting ntpd with the -x option.   That tells ntpd to step 
the clock, if needed, on a once only basis.  That should bring your 
server up with something a lot closer to the correct time.  Without 
that, it's going to take something like 4000 seconds to remove the 2000 
millisecond offset at the maximum slew rate of 500 PPM.   The "tinker" 
statement is only for the truly brave and truly knowledgeable!!

Also, I'd suggest removing the maxpoll keyword from your server 
statements.   Ntpd is designed to work properly with the default 
values.  You can improve on the defaults only in truly exceptional 
circumstances.

Finally, I'd add the "iburst" keyword to your server statements.   This 
causes the first eight requests to each server to be sent at two second 
intervals.  This gets ntpd the necessary information to start 
synchronizing your clock in twenty seconds instead of five minutes.




More information about the questions mailing list