[ntp:questions] ntpd doesn't set system time

David Woolley david at ex.djwhome.demon.co.uk.invalid
Wed Sep 12 10:28:28 UTC 2007


In article <46E72D52.7090707 at comcast.net>,
Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
> Laurent Monnoye wrote:

> > server keeps growing (almost 0.5 sec / hour):

Not the best of machines, but well within tolerable limits.  That assumes
that you mean 138ppm relative to true time.  If you mean 138ppm relative
to a free running timeserver, that could simply indicate that the clock
frequency error on the server differs from that on the client by about
638ppm, even though both are within the 500ppm correctable limits.
The frequency correction value on the client will help indicate this
(it will be end stopped at 500ppm).

Otherwise, we need the ntpq rv data for the server association, and
preferabley, also, for the client itself.

> >  timeserver         .LOCL.           1 u   47   64  377    0.150  -389.69
> > 38.104

It is considered very bad practice to run the local clock driver at
stratum zero.  Use about 5 if there is some none NTP software disciplining
the servers clock and about 10 if the server is free running.

> > restrict 127.0.0.1

As noted, this is the default.

> > Any idea how to force ntpd to keep local system time in sync?

Are you by any chance using a recent version of Windows as a time server,
or some other non-reference implementation ntp software.  Windows is more
honest about root distance in this case and will let it grow indefinitely,
causing the client to ignore the server as being too inaccurate (which
is true, of course).  Older versions of Windows also wouldn't work,
but always claimed a stratum of 2.

> It helps to have more than one server.  With only one server it's hard 

If you look, you will see he is using the local clock as reference on
the server.  As he hasn't said anything about that, one can reasonably
assume that this is not an appropriate use, with the clock disciplined
by other means, so, if he ran 4 servers, they would all have different
times and drift rates and would, one by one, get thrown out by the client.

> To get fast synchronization, it helps to use the "iburst" keyword in 
> each server statement; e.g.
> server timeserver1 iburst

Possibly true, but irrelevant to the problem.  He has reachability 377, so he 
is past this point.




More information about the questions mailing list