offset with ntpdate and ntpq ? - NTP

This is a discussion on offset with ntpdate and ntpq ? - NTP ; Hello, I have some questions regarding value offset with ntpq and ntpdate, these values are different or not? whether the value of the offset with ntpq is the difference local - peer? Regards Stavros Milos...

+ Reply to Thread
Results 1 to 8 of 8

Thread: offset with ntpdate and ntpq ?

  1. offset with ntpdate and ntpq ?

    Hello,

    I have some questions regarding value offset with ntpq and ntpdate, these
    values are different or not?
    whether the value of the offset with ntpq is the difference local - peer?

    Regards
    Stavros Milos

  2. Re: offset with ntpdate and ntpq ?

    Stavros Milos wrote:
    >
    > I have some questions regarding value offset with ntpq and ntpdate, these
    > values are different or not?
    > whether the value of the offset with ntpq is the difference local - peer?


    The offset is the difference between the local time and an estimate
    based on the weighted average of the "best of the last 8" measurements
    made on the set of servers and peers chosen for disciplining the clock.

    The local time is a smoothed estimate of the true time. The offset is
    an unsmoothed estimate of the time on the other servers. Normally the
    local time is a better estimate of true time, even if the actual time on
    the servers is perfect.

    Why are so many questions turning on the meaning of "Offset", in NTP
    jargon, today?

  3. Re: offset with ntpdate and ntpq ?

    Dnia 29-08-2008 o 00:55:09 David Woolley
    napisaƂ(a):

    > Why are so many questions turning on the meaning of "Offset", in NTP
    > jargon, today?



    Thanks for your answer. I am administrating large network (Intranet).
    I need to control time of several internal NTP servers, each located in
    different place/town.
    I would like to "read" a time of each remote NTP server and compare it to
    my local referential timeserver, just to examine if offset of each remote
    NTP server is not too high. So, the purpose is not to synchronize time to
    remote NTP servers, but to trace their time to keep a rule:

    "remopte NTP server time" - "my referential NTP server time" < 0.5s

    Regards
    Stavros Milos

  4. Re: offset with ntpdate and ntpq ?

    On 2008-08-29, Stavros Milos wrote:

    > I am administrating large network (Intranet). I need to control time
    > of several internal NTP servers, each located in different place/town.
    >
    > I would like to "read" a time of each remote NTP server and compare
    > it to my local referential timeserver, just to examine if offset of
    > each remote NTP server is not too high. So, the purpose is not to
    > synchronize time to remote NTP servers, but to trace their time to
    > keep a rule:
    >
    > "remote NTP server time" - "my referential NTP server time" < 0.5s


    0.5 sec is 500 milliseconds. ntpd should have no problem keeping your
    remote servers within that offset.

    One way to do this is add all of your remote NTP servers to your
    reference NTP server as 'noselect' servers. e.g.:

    server remote_NTP_server noselect

    You will need one of those lines for each of your remote NTP servers.

    Then you will be able to use the ntpq peers billboard ('ntpq -p') to
    view all the offsets between your remote NTP servers and your reference
    NTP server.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  5. Re: offset with ntpdate and ntpq ?

    Stavros Milos wrote:

    > I would like to "read" a time of each remote NTP server and compare it
    > to my local referential timeserver, just to examine if offset of each
    > remote NTP server is not too high. So, the purpose is not to synchronize
    > time to remote NTP servers, but to trace their time to keep a rule:
    >
    > "remopte NTP server time" - "my referential NTP server time" < 0.5s


    "Offset" doesn't really give you this information. If the ntpd design
    is valid, "offset" is either a measure of the network performance, or
    that ntpd has not been running long enough to work out which part of the
    offset is a true clock error and which part measurement variation. If
    you know of a way of telling the difference between a true error and
    measurement uncertainty, before ntpd is able to do so, you need to
    submit your algorithm to the NTP community.

  6. Re: offset with ntpdate and ntpq ?

    David Woolley writes:

    >Stavros Milos wrote:


    >> I would like to "read" a time of each remote NTP server and compare it
    >> to my local referential timeserver, just to examine if offset of each
    >> remote NTP server is not too high. So, the purpose is not to synchronize
    >> time to remote NTP servers, but to trace their time to keep a rule:
    >>
    >> "remopte NTP server time" - "my referential NTP server time" < 0.5s


    >"Offset" doesn't really give you this information. If the ntpd design
    >is valid, "offset" is either a measure of the network performance, or
    >that ntpd has not been running long enough to work out which part of the
    >offset is a true clock error and which part measurement variation. If
    >you know of a way of telling the difference between a true error and
    >measurement uncertainty, before ntpd is able to do so, you need to
    >submit your algorithm to the NTP community.


    Actually I have submitted such an algorithm but interest is low ( chrony
    does it much faster than does ntp) But that is irrelevant. If he has
    network errors of 500ms he has one very very weird network. For a local
    network the network errors are typically microseconds, not seconds. ( Note
    that offsets of seconds ntp will step so apparently it does know it is not
    random network errors. )


  7. Re: offset with ntpdate and ntpq ?

    Unruh wrote:
    > David Woolley writes:
    >
    >
    >>Stavros Milos wrote:

    >
    >
    >>>I would like to "read" a time of each remote NTP server and compare it
    >>>to my local referential timeserver, just to examine if offset of each
    >>>remote NTP server is not too high. So, the purpose is not to synchronize
    >>>time to remote NTP servers, but to trace their time to keep a rule:
    >>>
    >>> "remopte NTP server time" - "my referential NTP server time" < 0.5s

    >
    >
    >>"Offset" doesn't really give you this information. If the ntpd design
    >>is valid, "offset" is either a measure of the network performance, or
    >>that ntpd has not been running long enough to work out which part of the
    >>offset is a true clock error and which part measurement variation. If
    >>you know of a way of telling the difference between a true error and
    >>measurement uncertainty, before ntpd is able to do so, you need to
    >>submit your algorithm to the NTP community.

    >
    >
    > Actually I have submitted such an algorithm but interest is low ( chrony
    > does it much faster than does ntp) But that is irrelevant. If he has
    > network errors of 500ms he has one very very weird network. For a local
    > network the network errors are typically microseconds, not seconds. ( Note
    > that offsets of seconds ntp will step so apparently it does know it is not
    > random network errors. )
    >

    You get that kind of (wrong) offset when your machine is sitting at the
    end of an ISDN line that is heavily utilised in one direction only.
    This is the reason why I would like to have signaling to tell the
    ntp daemon "poll now".
    This can be _partly_ remedied with ( or similar )
    tinker huffpuff 160000
    you will still have the clock going south on occasion.

    This is a feature that is of interest to mobile platforms too
    ( "mobile" platforms need the "hey man there is a new door" signaling too ).

    uwe



  8. Re: offset with ntpdate and ntpq ?

    Uwe Klein wrote:
    >>

    > You get that kind of (wrong) offset when your machine is sitting at the
    > end of an ISDN line that is heavily utilised in one direction only.


    Exactly. If you do this with a modem, root distance goes so high that
    the measurements are rejected, but if you do it with something just that
    little bit faster, you end up with balancing positive and negative
    steps, as people start and finish their browser sessions.

    > This can be _partly_ remedied with ( or similar )
    > tinker huffpuff 160000


    tinker huffpuff was introduced precisely to cover this situation.

    > you will still have the clock going south on occasion.


    The best approach, though is to prioritise NTP traffic, but with the
    sort of speed of line for which this happens, you are unlikely to be an
    important enough customer of the ISP for them to do it at their end,
    unless they are enlightened enough to have done it for everyone.

+ Reply to Thread