[ntp:questions] Can't get time to sync with local time server

Richard B. Gilbert rgilbert88 at comcast.net
Fri Dec 15 14:07:15 UTC 2006

Arty wrote:

> Steve Kostecke wrote:
>>On 2006-12-14, Arty <arty-nospam at domain.tld> wrote:
>>>Why can't I set my time???
>>>server ntp.conf-------------
>>>server time.nist.gov prefer
>>>server pool.ntp.org
>>>server clock.isc.org
>>>driftfile /var/db/ntp.drift
>>>restrict default ignore
>>You've told ntpd to ignore all NTP packets form all addresses. Then you
>>neglected to tell ntpd that it is OK to accept NTP packets from your
>>time servers.
>>You may want to review the Restrictions HOWTO at
>>BTW: You're not going to be able to use 'restrict default ignore'
>>with a host name, such as pool.ntp.org, which resolves to multiple IP
>>Here's what your ntp.conf could look like:
>>| # server ntp.conf
>>| driftfile /var/db/ntp.drift
>>| # Allow only time service by default
>>| restrict default noquery nomodify notrap nopeer
>>| restrict nomodify
>>| # Remote time servers
>>| server time.nist.gov iburst
>>| server pool.ntp.org  iburst
>>| server clock.isc.org iburst
>>| # Authorized clients
>>| # They are allowed time service and may query ntpd
>>| restrict mask notrap nopeer nomodify
>>A couple of notes (that have no bearing on your current synchronization
>>1. You ought to use pool servers from your geographical area;
>>pool.ntp.org can resolve to any one of larger number of time servers
>>workd wide. See http://ntp.isc.org/pool or http://www.pool.ntp.org for
>>more information.
>>2. According to the Rules of Engagement (http://ntp.isc.org/rules) you
>>should not be directly using Stratum-1 time servers unless you meet
>>certain criteria (such as serving time a large number of clients). You
>>really ought to choose from the Public Stratum-2 server list (at
>>http://www.ntp.org/s2 or http://ntp.isc.org/s2) or just use the pool.
>>3. Using only 3 remote time servers doesn't leave you with any back up
>>if one of them "goes bad". You ought to consider using 4 or 5 remote
>>time servers.
>>># client ntp.conf-----------------------
>>>server prefer
>>Using 'prefer' here is of no benefit.
>>>driftfile /var/db/ntp.drift
> Thank you all (especially kostecke and rgilbert)!!!!
> It was a combo of things.
> 1. My config wasn't right. I misunderstood the use of restrict.
> Actually i'm still a bit confused.

Avoid "restrict" until you know what problem you are trying to solve! 
Then read the documentation carefully.  Very carefully!!!

> It seems as ntp makes a request to a time server, to have the time
> server set my time.  (as opposed to me requesting the time, and i'll set
> it myself).

Not quite.  The NTP daemon, ntpd, sends several request packets to the 
server to learn the round trip delay and determine how good the server 
and the network connection to it are.  It will then adjust your clock.

Ntpd will set, or step, your clock if it is off by more than the step 
threshold (128 milliseconds) and less than the panic threshold (1024 
seconds).  Otherwise it adjusts the frequency of the clock oscillator to 
"slew" the clock to the correct time.  It then readjusts the frequency 
to maintain the correct time.  When the clock is tuned to its 
satisfaction, ntpd will gradually increase the polling interval until it 
is querying the server once every 1024 seconds.

> To sync my time, i have to set my restrict options to allow a remote ip
> to set my time?

NO!  The remote server tells your NTP daemon what time it thinks it is. 
  It is customary to use at least four servers in order to be able to 
detect and reject a server that is offering incorrect time.  Your NTP 
daemon adjusts your clock.

> I'm still working on my ntp.conf files.  What is the absolute minimum
> access needed to sync my time?

If you are that paranoid about security, perhaps you should get a 
hardware reference clock, such as a GPS timing receiver, and forget 
about using internet servers.
> Here is what I want to do.
> On my ntp server:
> 1. sync my time from a public server
> 2. allow a subnet on my lan to sync from this server.
> 3. allow another subnet on my lan to to make sure i'm still in sync.
> 4. deny everything else from every one.
> On my hosts:
> 1. sync my time with from ntp server.
> 2. allow a subnet on my vlan check to make sure i'm in sync.
> 3. deny everything else from every one
> As far as monitoring goes, i think i can just check to make sure my
> stratum is not < 16 right ?

Try "ntpq -p" at least thirty minutes after you start ntpd.  It will 
show each server you are using, the reference that each server is using, 
  etc, etc.  Here is a sample with server id's obscured.

sunblok_$ ntpq -p
      remote           refid      st t when poll reach   delay   offset 
*GPS_ONCORE(0)   .GPS.            0 l    6   16  377    0.000    0.002 
xsunburn         .À¤.             1 u   43   64  377    0.452  -40.698 
+<server-1>     .PSC.             1 u   62   64  377   17.446    2.024 
+<server-2>     .CDMA.            1 u   47   64  377   16.967    3.776 
-<server-3>        2 u   24   64  377   15.796    2.071 
-<server-4>     2 u   43   64  377   12.664    1.833 
  LOCAL(0)        .LOCL.          10 l    4   64  377    0.000    0.000 

"remote" is the address of the server.
"refid" is the source of the server's time.
"st" is stratum.
"t" is type; "l" for local and "u" for ?? (maybe unknown)
"when" is the number of seconds since that server last responded
"poll" is the poll interval
"reach" is an octal number representing an eight bit shift register.  A 
one bit is shifted in from the right each time the server responds to a 
query; a zero bit is shifted in when the server fails to respond.  A 
value of "377" means the last eight queries received replies.
"delay" is the round trip delay in milliseconds
"Offset" is the difference between your clock and the server's clock.
"jitter" is a measure of the "noise" in the time value received.

If you configure it so, ntpd will write a "peerstats" file which you can 
analyze statistically or graphically to monitor server and network 
quality.  See:

More information about the questions mailing list