[ntp:questions] NTP-Question about "ntpq -p"
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