NTP-Question about "ntpq -p" - NTP

This is a discussion on NTP-Question about "ntpq -p" - NTP ; Hi! 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 ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: NTP-Question about "ntpq -p"

  1. NTP-Question about "ntpq -p"

    Hi!

    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
    server that the NTP 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.

    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
    lower level which I think would be more logical. There are actually some posts
    on the ntp support sites 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.

    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.

    Is that still ok? What is the acceptable range usually?

    I would be very glad if you could provide me with some help.

    thanks

    Manuel

    --
    Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
    Ideal f|r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

  2. Re: NTP-Question about "ntpq -p"

    On 2008-08-28, 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.


    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
    NTP Public Services Project - http://support.ntp.org/

  3. Re: NTP-Question about "ntpq -p"

    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
    synchronised.

    > 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.

  4. Re: NTP-Question about "ntpq -p"

    manuel.beicht@gmx.de (Manuel Beicht) writes:

    >Hi!


    >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
    >server that the NTP 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.


    Yes, * means it is the selected source. that ntp will slowly try to sync
    to.


    >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 ntp will carry out a step when it decides
    that that is a genuine (ie, that the minimum offset recorded during 8
    polling intervals) offset.
    If you have an offset of 1000 something is very wrong with your network
    connection or your system.


    >lower level which I think would be more logical. There are actually some posts
    >on the ntp support sites 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.


    It is slow to decrease the poll interval.


    >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.


    That is unusual. What kind of network connection do you have? A telephone
    modem connection? For a high speed connection, the usual offset is in the
    10s of microsecond range for a local server, and 100s of microseconds for a
    relatively local machine. Even half way across the continent with a delay
    of 45ms, the offset is 100s of microseconds.




    >Is that still ok? What is the acceptable range usually?


    >I would be very glad if you could provide me with some help.


    >thanks


    >Manuel


    >--
    >Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
    >Ideal f|r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer


  5. Re: NTP-Question about "ntpq -p"

    Unruh wrote:

    > Yes, * means it is the selected source. that ntp will slowly try to sync
    > to.
    >
    >

    Both * and + mean this.

    * means it is the source used for the upstream stratum, root delay and
    root dispersion used in the calculation of their downstream counterparts.

  6. Re: NTP-Question about "ntpq -p"

    Unruh wrote:
    > manuel.beicht@gmx.de (Manuel Beicht) writes:
    >
    >> Hi!

    >
    >> 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
    >> server that the NTP 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.

    >
    > Yes, * means it is the selected source. that ntp will slowly try to sync
    > to.
    >
    >
    >> 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 ntp will carry out a step when it decides
    > that that is a genuine (ie, that the minimum offset recorded during 8
    > polling intervals) offset.
    > If you have an offset of 1000 something is very wrong with your network
    > connection or your system.
    >


    Unless he introduced the error deliberately in order to "test" NTP.

    >
    >> lower level which I think would be more logical. There are actually some posts
    >> on the ntp support sites 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.

    >
    > It is slow to decrease the poll interval.
    >
    >
    >> 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.

    >
    > That is unusual. What kind of network connection do you have? A telephone
    > modem connection? For a high speed connection, the usual offset is in the
    > 10s of microsecond range for a local server, and 100s of microseconds for a
    > relatively local machine. Even half way across the continent with a delay
    > of 45ms, the offset is 100s of microseconds.
    >
    >
    >
    >
    >> Is that still ok? What is the acceptable range usually?

    >
    >> I would be very glad if you could provide me with some help.

    >
    >> thanks

    >
    >> Manuel

    >
    >> --
    >> Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
    >> Ideal f|r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer


  7. Re: NTP-Question about "ntpq -p"

    Richard B. Gilbert wrote:

    >
    > Unless he introduced the error deliberately in order to "test" NTP.
    >


    If he did, it is a case of garbage in and ntpd is under no obligation to
    expeditiously correct for it. You can't evaluate the dynamic response
    of ntpd based on unreasonable stimuli.

  8. Re: NTP-Question about "ntpq -p"

    David Woolley wrote:
    > Richard B. Gilbert wrote:
    >
    >>
    >> Unless he introduced the error deliberately in order to "test" NTP.
    >>

    >
    > If he did, it is a case of garbage in and ntpd is under no obligation to
    > expeditiously correct for it. You can't evaluate the dynamic response
    > of ntpd based on unreasonable stimuli.


    You don't need to dig too deeply in the archives to find cases of people
    doing just that!

  9. Re: NTP-Question about "ntpq -p"

    Richard B. Gilbert wrote:
    > David Woolley wrote:
    >> Richard B. Gilbert wrote:
    >>
    >>>
    >>> Unless he introduced the error deliberately in order to "test" NTP.
    >>>

    >>
    >> If he did, it is a case of garbage in and ntpd is under no obligation
    >> to expeditiously correct for it. You can't evaluate the dynamic
    >> response of ntpd based on unreasonable stimuli.

    >
    > You don't need to dig too deeply in the archives to find cases of people
    > doing just that!


    I'm very well aware that it is a very common way of "acceptance testing"
    ntpd for people who don't understand it. However, the correct response
    to such a large offset is to ignore it as long as possible, as, in real
    operation, if it doesn't represesnt a fault that needs fixing outside of
    ntpd, it represents a temporary network disturbance and the local clock
    time is still actually valid.

+ Reply to Thread