Mike Chirico on 23 Mar 2004 14:31:02 -0000


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[PLUG] ntp...how do I know it's working? (Mark M. Hoffman)


> Date: Mon, 22 Mar 2004 20:37:10 -0500
> From: "Mark M. Hoffman" <mhoffman@lightlink.com>
> To: plug@lists.phillylinux.org
> Subject: Re: [PLUG] Re: ntp...how do I know it's working?
> Reply-To: plug@lists.phillylinux.org
>
> * Mike Chirico <mchirico@comcast.net> [2004-03-22 18:32:30 -0500]:
>
> > Thank you.  There is a "reject" on my system using the "as" command,
but
> > I assume that's normal when authentication is disabled. Comparing
your
> > "frequency" and "stablility" with the values on my server leaves to
> > wondering if something isn't working correctly.  It seems like I
should
> > have numbers here, but I'm still reading the documentation.
> >
> >
> > ntpq> pe
> >      remote           refid      st t when poll reach   delay
offset
> > jitter
> >
========================================================================
> > ======
> >  tock.usno.navy. 0.0.0.0         16 u    -   64    0    0.000
0.000
> > 4000.00
>
> You're right, it's not working.  A "*" in the first column means that
the
> client has decided to sync with that remote.  It will take some time
to
> get to that point... within 5 minutes or so.  E.g.
>
> $ /usr/sbin/ntpq -pn
>
>      remote           refid      st t when poll reach   delay   offset
jitter
>
========================================================================
======
> *10.17.17.3      132.236.56.250   3 u  146  512  377    0.223    0.927
0.108
>
> Also, the "reach" attribute (377) tells you that the remote has
responded to
> a client request successfully the last 8 times it tried. [1]  The zero
in
> your case indicates a problem, perhaps with network connectivity or
maybe
> your firewall.  Can you ping tock.usno.navy.mil (guessing the rest of
the
> remote address from the chopped output above) ?  I can ping it from
here.
>

Thanks!  I kept looking until I found the source of the problem.  It
turned out my /etc/ntp.conf and /etc/ntp/step-tickers were configured
incorrectly

Here's the working /etc/ntp.conf

# Simple client-only ntp configuration.
server timeserver1.upenn.edu
restrict 128.91.2.13
server tock.usno.navy.mil
restrict 192.5.41.41
server 128.4.40.12
restrict 128.4.40.12
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
driftfile /etc/ntp/drift
restrict default ignore
restrict 127.0.0.0 mask 255.0.0.0
authenticate no

The restrict values are the ip address. For instance,
timeserver1.upenn.edu is 128.91.2.13, tock.usno.navy.mil is 192.5.41.41.

Here's /etc/ntp/step-tickers

timeserver1.upenn.edu
tock.usno.navy.mil
128.4.40.12

Now, when I issue the following:
ntpq -pn
     remote           refid      st t when poll reach   delay   offset
jitter
========================================================================
======
+128.4.40.12     128.175.60.175   2 u   36   64  377   53.072   18.416
14.043
 127.127.1.0     127.127.1.0     10 l   33   64  377    0.000    0.000
0.008
+128.91.2.13     128.4.40.12      3 u   21   64  377   21.804    5.078
1.665
*192.5.41.41     .USNO.           1 u   32   64  377   32.578    6.131
6.011

So it looks like "tock.usno.navy.mil" is a little slow; but, the other
servers are working.

Thanks for you help.

Mike Chirico


___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug