[ntp:questions] Re: Problem with good synchronization.

Richard B. Gilbert rgilbert88 at comcast.net
Fri Oct 15 13:53:13 UTC 2004

Marcin Okraszewszki wrote:

> Hi,
> I need to synchronize computers' clocks very tightly. I mean clocks
> offset shouldn't exceed 50ms. All computers are in the same LAN, so in
> fact network traversal time isn't very big. But with default settings I
> find that offset even goes to 700ms, and from time to time there are
> some step clock changes that are highly undesirable (at least with
> amount of 500ms).
> I tried to set minpoll 4 and maxpoll 5 turned step 0 (to avoid sudden
> time changes) The results are as fallows: absolute value of offset has
> reduced to average 70ms with standard deviation 90ms and maximum 350ms.
> This is not good enough. What is even worse, suddenly the time offset to
> server was 60s (not ms)!! And it happened in all clients at the same
> time, which for me means that something happened with the time on the
> server, but there is nothing about it in the system log.
> Is there any way to improve this situation?
> The ntp server is running Windows 2000 (ntpd 4.1.72) and clients are
> Linuxes (ntpd 4.1.1). To measure the offset I use ntptrace. The Windows
> is not synchronized to any other source.
> Thanks for help.
> Marcin Okraszewski
This should work a whole lot better if you synchronize your NTP server 
to an external time source.

Think for a moment about what's happening here.  The clients, by design, 
assume a stable and accurate source of time (stability is the most 
important thing here).  This means that when a client finds an error in 
its time or clock frequency, it assumes that its local clock is in error 
and makes a correction.  The problem is that the server is drifting as 
wildly as the clients!!!  The client is trying to compensate for both 
its own drift and also for the server's drift.  I can't see any way in 
which this can work very well!!!

Get your server synchronized with a network server traceable to NIST or 
a reference clock traceable to NIST and your clients should synch up 
within twenty-four hours  Note also that Windows is not a great platform 
to use as a time server; it loses in interrupts which means it loses 
clock ticks.

The ability to use an unsynchronized local clock as a server was 
intended to allow a clock that has lost synchronization to act as a 
clock of last resort for, at most, a few hours while necessary repairs 
are made.

More information about the questions mailing list