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

Steve Kostecke kostecke at ntp.org
Thu Aug 28 20:10:08 UTC 2008


On 2008-08-28, Manuel Beicht <manuel.beicht at gmx.de> 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.

The '*' indicates the time source that this ntpd has selected as its
'sys_peer' (i.e. the source that the ntpd is currently "synced" to).

> Is this star a must because I have seen the polling sometimes and the
> time mostly accurate but the "*" is missing.

If you don't see the '*' your ntpd is not synced to any time source.

> So does the server have to have a "*" to be synched? In ntp
> documentation I read it just means that "*" denotes the server that
> the NTP client

ntpd is both a server and a client.

> is synching to but not necessarily that they are IN synch. I am asking
> so far I considered any server without a "*" out of synch.

ntpd will not sync to a remote time server which is not itsself synced
to something.

> 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

If you see an offset of 1000.xxx in ntpq that is 1000 milliseconds (ms)
or 1 second. The default behavior for an offset of this magnitude is to
correct it with an instantaneous step (see below).

> the polling is at 128 or at 256

The poll period is expressed in seconds.

> instead of 64 or a lower level which I think would be more logical.

Why do you think this is the case?

The maximum slew rate for ntpd is 500PPM or 0.0005 sec / sec (half a
millisecond per second).

Calculating the time required to amortize a 125ms (or 1/8 sec) offset is
left as an exercise for the reader.

> There are actually some posts on the ntp support sites

If those sites are not a part of ntp.org you should take them with a
grain of salt.

> that mention using custom polling parameters based on the offset and
> latency ect...that do polling at 10 min 15 max and there is some type
> of algorithm to find a match for anyone site.

Unless you _really_ understand what you are doing you should not tinker
with these settings.

Assuming that you have not changed any of the defaults...

ntpd will step the clock if the offset is greater than 128ms (shown in
ntpq -p as 128.xxx)

ntpq will slew the clock (i.e. slow it down or speed it up) if the
offset is less than 128ms

> Also what is acceptable offset and jitter? We currently experience
> 20-40ms offset and 20-30ms jitter. sometimes it is up to 100-120ms
> offset.

The ntpq peer billboard (the output of 'ntpq -p') displays the values in
miliseconds. For example:

     remote          refid    st t when poll reach delay offset jitter
======================================================================
 6s-ntp          .ACST.       16 u    -   64    0  0.000  0.000 0.002
*ntp0.kostecke.n 192.168.19.2  3 u  225 1024  377  0.723 -3.463 1.889

Here the delay is 0.723ms, the offset is -3.463ms and the jitter is
1.889ms.

If you are actually seeing 20.xxx to 40.xxx offset that is a bit higher
than you should be able to achieve over a WAN or The Internet.

What type of internet connection do you have?

-- 
Steve Kostecke <kostecke at ntp.org>
NTP Public Services Project - http://support.ntp.org/




More information about the questions mailing list