[ntp:questions] NTP-Question about "ntpq -p"

David Woolley david at ex.djwhome.demon.co.uk.invalid
Thu Aug 28 22:46:41 UTC 2008

Manuel Beicht wrote:
> I have some questions regarding synchronization and the output of "ntpq -p".
> For example what is the significance of the "*" for example when you run ntpq
> -p. Is this star a must because I have seen the polling sometimes and the time
> mostly accurate but the "*" is missing. So does the server have to have a "*"
> to be synched?  In ntp documentation I read it just means that "*" denotes the

The *client* has to have a "*" against one of its servers to be 

> server that the NTP client is synching to but not necessarily that they are IN

That's an over-simplification.  It is the server that determines the 
stratum and root distance/dispersion reported to downstream clients, but 
the time is, normally, synchronised to a combination of all servers with 
* or +.

> synch. I am asking so far I considered any server without a "*" out of synch.
> Then I noticed the polling is dynamic but it seems to be too long with some
> intervals and in particular too long when there is an offset. For example if
> we have an offset of 1000 the polling is at 128 or at 256 instead of 64 or a

If you have an offset of 1000, you need to fix the 
network/software/hardware problem that is causing that.  Although a lot 
of people feel that ntpd fails to respond adequately rapidly to obvious 
error conditions, an offset of 1 second is too high to put any credence 
at all on the time source, except on start up.  Either you have lost 
interrupts, which you need to address outside of nptd, or you have very 
large asymmetric network delays, and the measured "offset" bears little 
resemblance to the error in the internal time, and much more to the 
difference between uplink and downlink propagation times.
> Also what is acceptable offset and jitter? We currently experience 20-40ms

< 128ms at the 99 percentile.  Apart from that it depends on the 
structure of your timing network.  For a PPS connected GPS timing 
receiver, it should probably be +/-500ns at the 95 percentile.  For a 
consumer ADSL connection with only light traffic, maybe +/-10ms at the 
90 percentile, dropping to maybe +/- 1ms for an essentially idle one at 
a quiet time of day.  If there is a w32time system upstream, I suspect 
that +/- 40ms at the 95 percentile might be quite reasonable.

> offset and 20-30ms jitter. sometimes it is up to 100-120ms offset.

Typically, you should compute the statistics over at least a day.

More information about the questions mailing list