[ntp:questions] NTP client configuration

Steve Kostecke kostecke at ntp.org
Fri Sep 28 03:22:20 UTC 2012


On 2012-09-27, Benjamin CABUT <benjamin.cabut at rsacosmos.com> wrote:

> -> our time source is the local clock of one computer. wich I guess is 
> accurate.
>      I mean, we don't need to get the correct time in our application, 
> but we need that all computers shares the same time even if it wrong 
> compared to UTC.

This is a common fallacy.

A cluster of ntpds which do not have access to a stable time reference can
only chase a moving target. So those clocks can not be brought into
tight synchronization.

UTC is a ubiquitous stable time reference which can be inexpensively
acquired from high quality time sources via the public Internet, timing
GPS receivers and other radio clocks, or even modem dial-up. As a side
effect of using a UTC source your clocks will be set to the correct
time. And there is something to be said for having log and transaction
time stamps correlate with reality.

> -> you are right our problem is that ntpd takes time before accepting 
> time is broken, and during all this time our software do not work well 

Then you should not start your software until the clocks are "close
enough".

> BUT I don't think the problem wome from the server (local clock).
> Because the problem happen on one client only, when this client
> computer is doing some action that I guess are making trouble to ntp.
> Actualy my computer is playing audiofiles throught a special audio
> board. I don't know why it affect ntp client, but it does...

If this client is one of the systems running your time sensitive software
why are you running (non-essential?) tasks which are known to cause a
problem?

> I also have a problem when we start the computers in the morning, in 
> this case the server need some time to accept client request + client 
> need time to adjust there clock.

Actually the issue is that the client will not accept the server's
responses until the server declares that it is "synced".

If your server is configured with the Undisciplined Local Clock
127.127.1.x (aka "LOCAL") you can reduce the initial sync time by
setting minpoll to the lowest possible value. You should be able to
reduce the server's initial "self-sync" time to about 60 seconds.

If your server is configure with Orphan Mode then it will "self-sync"
almost immediately.

The clients should all be configured with "iburst" becuase it will
reduce their initial sync time to ~20 seconds.

-- 
Steve Kostecke <kostecke at ntp.org>
NTP Public Services Project - http://support.ntp.org/



More information about the questions mailing list