[ntp:questions] Unable to get time from the internet using NTP

Dew Wrobel drew.wrobel at gmail.com
Mon Oct 5 19:34:01 UTC 2009


On Oct 5, 2:17 pm, "Richard B. Gilbert" <rgilber... at comcast.net>
wrote:
> Dew Wrobel wrote:
> > I have to setup a couple of servers that will get their time from the
> > internet.
>
> > I have following the steps listed athttp://www.pool.ntp.org/
>
> > The following is the contents of ntp.conf:
>
> > driftfile /drift/ntp.drift
> > server 0.us.pool.ntp.org
> > server 1.us.pool.ntp.org
> > server 2.us.pool.ntp.org
> > server 3.us.pool.ntp.org
>
> > When I start NTP, the start up hands with ntpdate trying to get the
> > time from the servers.  I have verified that the server names do
> > verify in DNS.
>
> > Do I need to pick a different set of servers?  Any idea/suggestions
> > would be greatly appreciatd.
>
> > Thanks
>
> Ntpdate is "deprecated".  Perhaps you should eliminate ntpdate and start
> ntpd with the "-g" option.  This option tells ntpd to find out what time
> it is by querying the servers and then setting that time.
>
> The results should be similar either way but ntpd -g is the documented
> and supported way to set the time at startup.
>
> If you add "iburst" to each server line in your ntp.conf you should get
> a faster startup.  Iburst will cause ntpd to send an initial burst of
> eight requests at two second intervals.  The replies fill the "filter
> pipeline" and should get you synchronized a little faster.
>
> Ntpd will need about ten hours to achieve the accuracy it's capable of.
>   Initially you should have a reasonable approximation of the correct
> time; e.g. within, say, 100 milliseconds.   The longer it runs the
> better the time will get.
>
> If you can possibly avoid rebooting and/or restarting NTPD you will get
> much better time.

The call to ntpdate is part of the RC script that comes with the OS.
I checked an option under /etc/sysconfig/ntp to not call ntpdate on
start.

I found a web page about debugging NTP and came across running ntpq
with various parameters.  here is the output from that.
I can't help and wondering, based on the as option, it sounds that the
time servers being used are reject.

Aside from what servers I'm using, I don't have to do anything else,
do I?

ntpq> pe
     remote           refid      st t when poll reach   delay
offset  jitter
==============================================================================
 ntp1.truetime.c .INIT.          16 u    -   64    0    0.000
0.000   0.001
 zinc.ops.tns.it .INIT.          16 u    -   64    0    0.000
0.000   0.001
 ntp2.usno.navy. .INIT.          16 u    -   64    0    0.000
0.000   0.001
ntpq> as

ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 53536  8000   yes   yes  none    reject
  2 53537  8000   yes   yes  none    reject
  3 53538  8000   yes   yes  none    reject
ntpq> rv 53536
assID=53536 status=8000 unreach, conf, no events,
srcadr=ntp1.truetime.com, srcport=123, dstadr=172.21.100.26,
dstport=123, leap=11, stratum=16, precision=-20, rootdelay=0.000,
rootdispersion=0.000, refid=INIT, reach=000, unreach=0, hmode=3,
pmode=0, hpoll=6, ppoll=10, flash=00 ok, keyid=0, ttl=0, offset=0.000,
delay=0.000, dispersion=16000.000, jitter=0.001,
reftime=00000000.00000000  Thu, Feb  7 2036  1:28:16.000,
org=00000000.00000000  Thu, Feb  7 2036  1:28:16.000,
rec=00000000.00000000  Thu, Feb  7 2036  1:28:16.000,
xmt=00000000.00000000  Thu, Feb  7 2036  1:28:16.000,
filtdelay=     0.00    0.00    0.00    0.00    0.00    0.00    0.00
0.00,
filtoffset=    0.00    0.00    0.00    0.00    0.00    0.00    0.00
0.00,
filtdisp=   16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0
16000.0
ntpq>




More information about the questions mailing list