[ntp:questions] Re: Question about ntp log messages and logging interval

David Woolley david at djwhome.demon.co.uk
Tue Sep 12 21:26:51 UTC 2006


In article <R4adnZdGoqCNZpvYnZ2dnUVZ_q2dnZ2d at comcast.com>,
Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
> Jeff Boyce wrote:
> 
> > 1. I am wondering if this is an indication of a properly (or improperly) 
> > running ntp system?

Time steps in the same direction are an indication of a failing system.
Either, your crystal is out by more than 500ppm, or, more likely, 
especially for Red Hat, is that you are losing clock interrupts.  A
contributory factor tends to be the use of HZ=1000 and IDE device
drivers with interrupt latencies of more than 1ms.  It is strongly
reccommended that HZ be no more than 100.

> > 3. How do I find out what the standard polling interval is, and how 
> > would I reduce the interval if I wanted to?

The poll column in your ntpq output.  On a system that is working well, 
this will soon reach 1024.  Currently you are showing the minimum 
end of the normal range, which would normally only be the case during
startup.  You shouldn't change the limit values and the system will 
choose the optimum value within that range.  A normally operating
ntpd will never make abrupt time steps and using too short a poll
interval will simply cause the phase to wander a lot faster.  ntpd
attempts to anticipate errors, rather than wipe them out at each poll.

Reducing the poll interval below the current one may get you barred from
the servers.  Typically polling at an interval of less than 1 minute
is considered abuse of the server.

> That does not look like a happy system to me!  Your ntpq "banner" shows 
> high values of jitter and long round trip delays.   Since you are using 

These are not causing the problem and the jitter may be an effect.
Without knowing the communication hardware, it is not possible to say
that the delays are excessive, e.g. they are better than can be 
achieved using high speed modems.

However if we are to air our pet themes on bad configurations, I would
also ask why the local clock driver is configured.  This should only be
configured on servers and only if one understands why one is doing it.
On a client, it does nothing useful at all.  On a server, it may result
in bad times seeming good.

> second intervals.  It's highly improbable that they would in any case 
> but your internet connection seems to be introducing quite a bit of 
> randomness in the transmission times!

I believe the recent time step could also cause a high jitter value.

> What can you do?  Try to find a server or two with a round trip delay 
> less than twenty milliseconds.  Servers should be physically close to 

There's no point in doing any of this until he has a stable lock on
the servers he is currently using, which probably means rebuilding the
kernel with a sensible HZ value, but may mean replacing the mother board.
The delays shown in the ntpq snapshot are not enough to cause steps in
their own right.




More information about the questions mailing list