[ntp:questions] Re: ntpd looses sync, I must always restart: please help

Dale Worley worley at dragon.ariadne.com
Thu Oct 30 22:20:25 UTC 2003


luca at pacor.de (Luca) writes:
> Now, my problem is that I must restart the daemon at least once a day
> because I cannot see any server anymore.

The root cause is that when NTP starts, it opens a separate socket on
every interface address that is present at the time.  (This is for
good but technical reasons.)  When the address of your interface
changes, NTP's socket becomes effectively disconnected, and can no
longer send or receive packets.  That is why all the 'reach' values
become 0.

In the short run, the solution is to restart NTP once or twice a day.
I *think* that once NTP gets a good value for the computer's clock
drift, that restarting it daily will not degrade its accuracy much.
But you should check with the experts on that.

> I also tried to set up many
> servers and peers (I decided to be stratus 2, is that wrong?) because
> I thought it depended on the servers, but that did not do either ...

NTP examines the servers/peers that it has and selects one to
synchronize to.  So if you have enough servers that NTP can always see
one that is delivering quality time, that is enough.  Usually, three
servers are adequate for all but the most paranoid applications.

> fudge  127.127.1.0 stratum 2    # LCL is unsynchronized

Don't put the local clock at stratum 2.  It is much better to use a
high stratum, like 10, so that any NTP obtaining time from your NTP
when it is synced to the local clock has an obviously high stratum.

http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver1.html

    *NEVER* configure this driver to operate at a stratum which might
    possibly disrupt a client with access to a bona fide primary server

I also see that the 127.127.1.x is listed twice:

    server 127.127.1.0              # local clock (LCL)
    # fudge  127.127.1.0 stratum 10 # LCL is unsynchronized
    fudge  127.127.1.0 stratum 2    # LCL is unsynchronized

    # The internal PC clock is peered to let it be set by the NTP daemon
    peer  127.127.1.1

There's no point doing that, and there is also no point marking it
'peer', since NTP can't give time *to* it.

Dale



More information about the questions mailing list