[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:
> 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
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
More information about the questions