ntpq -p "when" - NTP

This is a discussion on ntpq -p "when" - NTP ; What does the "when" field from the ntpq -p output means? The man pages say its seconds since the last packet was received but some documentation online say the it resets to 0 when is equal to the poll. Is ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: ntpq -p "when"

  1. ntpq -p "when"

    What does the "when" field from the ntpq -p output means?

    The man pages say its seconds since the last packet was received but
    some documentation online say the it resets to 0 when is equal to the
    poll.

    Is it set when a sync is requested or received?
    Is is possible for the "when" count to be greater that the polling
    interval in case no packet was received (server is unreachable)? --
    Has anyone seen it going greater than the poll interval?


  2. Re: ntpq -p "when"

    On 2007-11-09, lmr wrote:

    > What does the "when" field from the ntpq -p output means?


    The number of seconds since ntpd last received an answer to a poll.

    > The man pages say its seconds since the last packet was received but
    > some documentation online say the it resets to 0 when is equal to the
    > poll.


    Where did you see this?

    > Is it set when a sync is requested or received?


    It displays the number of seconds since ntpd last RECEIVED an answer to
    a POLL. It has nothing to do with synchronization.

    > Is is possible for the "when" count to be greater that the polling
    > interval in case no packet was received (server is unreachable)? --


    Yes, it is.

    > Has anyone seen it going greater than the poll interval?


    Yes, I have.

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

  3. Re: ntpq -p "when"

    lmr wrote:
    > What does the "when" field from the ntpq -p output means?
    >
    > The man pages say its seconds since the last packet was received but
    > some documentation online say the it resets to 0 when is equal to the
    > poll.
    >
    > Is it set when a sync is requested or received?
    > Is is possible for the "when" count to be greater that the polling
    > interval in case no packet was received (server is unreachable)? --
    > Has anyone seen it going greater than the poll interval?
    >


    I have seen the "When" field claim *days* since a server last responded.
    It's rare to see something like that since most servers are available
    24x7 but a server may encounter serious problems, either hardware or
    software, that require days to fix. If there were any NTP servers in
    New Orleans when hurricane Katrina struck, they might have gone down for
    days, weeks, months, or forever!

    This suggests that a robust configuration should use a number and
    variety of servers that cannot all be wiped out in the same disaster.


  4. Re: ntpq -p "when"

    "Richard B. Gilbert" wrote in message
    news:4735060E.7090705@comcast.net...
    [...]
    > This suggests that a robust configuration should use a number and
    > variety of servers that cannot all be wiped out in the same disaster.


    Robustness is relative. If that disaster is likely to wipe _you_ out,
    the servers don't matter much.

    Groetjes,
    Maarten Wiltink



  5. Re: ntpq -p "when"

    Maarten Wiltink wrote:
    > "Richard B. Gilbert" wrote in message
    > news:4735060E.7090705@comcast.net...
    > [...]
    >
    >>This suggests that a robust configuration should use a number and
    >>variety of servers that cannot all be wiped out in the same disaster.

    >
    >
    > Robustness is relative. If that disaster is likely to wipe _you_ out,
    > the servers don't matter much.
    >
    > Groetjes,
    > Maarten Wiltink
    >
    >


    If the disaster wipes ME out, it's not my problem any longer! ;-)


  6. Re: ntpq -p "when"

    Steve Kostecke wrote:

    >> Is it set when a sync is requested or received?

    >
    > It displays the number of seconds since ntpd last RECEIVED an answer to
    > a POLL. It has nothing to do with synchronization.


    Actually, it can get a little more complicated than that.

    First, remember that although when is printed as an interval,
    it is the interval since the REC timestamp for that association
    and the current system time, so it can be affected by clock
    steps in the intervening time.

    Also, it is only the REC timestamp if the REC timestamp is not
    zero. Recall that after a certain period of time of non-response,
    the polling data for an association is cleared. When that happens,
    the REFTIME for the association is used instead. And the REFTIME
    can be very nearly the same as the last REC time, or it could be
    wildly different.

    Brian Utterback

+ Reply to Thread