[ntp:questions] NTP driving me nuts!

JCA 1.41421 at gmail.com
Sun Dec 31 17:38:37 UTC 2006


On 12/29/06, Danny Mayer <mayer at ntp.isc.org> wrote:
> JCA wrote:
> >      The ntp.conf configuration files of A and B are identical:
> >
> > server  127.127.1.0
> > fudge   127.127.1.0 stratum 10
> > server        192.168.0.1
> > # server reloj.kjsl.com
> >
> > driftfile /etc/ntp/drift
> > multicastclient                 # listen on default 224.0.1.1
>
> The multicast address is required in order for it to receive multicast
> packets. See html/confopt.html. If you aren't doing authentication of
> the server you need to turn it off:
> disable auth

   OK.

>
> > broadcastdelay  0.008
> >
> >     192.168.0.1 is the IP address of C in my LAN. In the ntpq traces
> > above B's ntp.conf file was using
> >
> >     server reloj.kjsl.com
>
> Does DNS resolve this to the same address?

   Yes.

> >
> > rather than
> >
> >    server 192.168.0.1
> >
> >     C's ntp.conf configuration file:
> >
> > server  127.127.1.0     # local clock
> > fudge   127.127.1.0 stratum 10
> >
> > server reloj.kjsl.com
> > server ntp1.sf-bay.org
> >
> > driftfile /var/run/ntp.drift
> >
>
> Is C not a multicast server?

   No.

>  If not is there another server serving as a
> multicast server?

    Not in my LAN.

> Otherwise, either turn off the multicastclient in A
> and B or add the broadcast address line to C's ntp.conf.

   OK.

> >    If in A's and B's configuration files I use the line
> >
> >    server reloj.kjsl.com
> >
> > instead of
> >
> >   server 192.168.0.1
> >
> > then A and B keep the time all right. C keeps the time all right with
> > the configuration file above.
> >
>
> Is reloj.kjsl.com on that address or a different address?

    reloj.kjsl.com is an external server - nothing to to with my LAN.
192.168.0.1 is the IP address of C in my LAN - nothing to do with
reloj.kjsl.com.

> If it's the
> same address as C then you need to remove that line from C's configuration.
>
> >    Interestingly, I have another Linux box D in my LAN that seems to
> > be keeping in sync with C with the following ntp.conf file:
> >
> > restrict default ignore
> > restrict 192.168.0.1 mask 255.255.255.255 nomodify notrap noquery
> >
> > restrict 127.0.0.1
> >
> > server 192.168.0.1
> > fudge   127.127.1.0 stratum 10
> >
> > driftfile /var/lib/ntp/drift
> > broadcastdelay  0.008
>
> This has no effect for a system not acting as a broadcast/multicast client.

   OK.

> >
> > authenticate yes
> > keys            /etc/ntp/keys
>
> Do you have keys set up to authenticate? If so you need "enable auth"
> and not "authenticate yes".

   I have no keys.

> >
> >    I could of course change A's and B's ntp.conf files accordingly and
> > see what happens. However, were this to lead to A and B synchronizing
> > with C all right, it still would not explain why A and B had been
> > synchronizing with C with no problems until recently.
>
> You network may have changed or a firewall may have been added or DNS
> has changed.

   I don't know what my ISP does with the network, but I know that my
setup is the same as before.

   The problem seems to be in C. C keeps in sync with the external
server all right. If either A or B take their synchronization from C,
they stay in sync for some time - hours, maybe a day. After that, they
don't seem to get any synchronization ticks from C anymore, and their
clocks start to drift big time.

   If, on the other hand, either A or B get their synchronization from
the same external host as C does, then they keep in sync indefinitely
all right. C keeps in sync with the external clock all right.

   I am totally puzzled by this behavior. Might it be that a dying
clock battery in one or more of my PCs could be the cause. I mean, is
it not the case that when a battery is losing power the clock becomes
more and more erratic, so much so that ntpd might altogether refuse to
adjust it? Can this possibility be explored with the NTP software?



More information about the questions mailing list