[ntp:questions] Re: NTP clients not syncing up to servers?

Tom Smith smith at cag.zko.hp.com
Tue Oct 11 23:53:15 UTC 2005

Ted Beatie wrote:
>>If ntpd finds an offset of more than 1000 seconds, it will
>>terminate itself unless "-g" is present on the ntpd command
>>line. In that case, it will make one such adjustment and will
>>terminate itself if a second such adjustment is required.
> I'm confused then;
>   server-04:~# ps aux|grep ntpd
>   root     389  0.0  0.1  2328 2320 ?      SL   Jun13   0:05 /usr/sbin/ntpd -g
> This instance of ntpd has been running since Jun13.  Shouldn't it have
> terminated by now?  (not that I want it to terminate..  what I want is
> for it to say, "ok upstream server, I think you're on crack, but I'm
> going to believe you anyway.")

The offsets shown by ntpq are in milliseconds. Does that answer the
question? Otherwise, I don't really know what the status of "server-04"
is, so I can't evaluate whether anything is amiss or not.

>>Also make sure that each ntpd instance has at least 4
>>reliable, consistent, and _working_ lower-stratum servers
>>configured before you even start ntpd for the first time.
> What if we can't guarantee that?  The docs certainly seem to say that
> the more the better, but that only one is actually required.  Some of
> our deployments have public internet access, in which case, we can
> populate the ntp.conf file on the gateway machines with as many servers
> as we'd like.  But a fair number of our deployments don't have outbound
> internet access, and have only one internal NTP server, if even that.
> And yet, we still want at a minimum, for all of our machines to be in sync.

If you can't guarantee that, you'll have to settle for poor and unreliable
timekeeping, not to put too fine a point on it. Obviously, you have to
have at least one working server. What if you only have one configured
and it is down? What if it is malfunctioning and reporting the wrong
time? With multiple servers, NTP can cull out the bad boys. 4 is the
minimum you need to provide a valid statistical sample and n+1

>>In any case, you should make no judgments about whether
>>ntpd is working properly or not until it has been running
>>for several hours, sometimes 2 days or more on a previously
>>unitialized system.
> This is also a problem.  Given our situation, the gateways and servers
> all get powered on at roughly the same time.  Ideally, what we would
> like is for the servers to sync up to the gateways, no matter what they
> think of the accuracy of them, just so that they are all in sync.  Then,
> if the gateways themselves get more reliable information, from internal
> or external upstream servers, that the whole system asjusts accordingly.

Nothing will synch to the gateways until the gateways are themselves
synched. You have to start with them. Make sure they step to the
right time on boot (with ntpdate -b ....], synch to their servers
as quickly as possible (add iburst to the end of each server line),
and hope that the gateways' clients can be happy with a clock
skew for a while after they boot. If there is a possibility that
the gateways will not be able to reach any servers at the time they
boot, you would have to configure the local undisciplined clock at
a high stratum as a server on at least one of those to allow the
clients to be able to synchronize to something, or you will just
have to live with letting all of the systems float with their own
time until the real servers become accessible.

There is some other discussion in here that suggests that you may
be using Windows systems running W32time as time servers. That won't
work. Don't even try. If that's what you've got, sort that out first.


More information about the questions mailing list