NTP jitter very large - NTP

This is a discussion on NTP jitter very large - NTP ; I have a very strange problem that started a few days ago. The server is running kernel 2.4.28 and has been running for several years without any issues. When starting the ntp service, the time is initially set correctly using ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: NTP jitter very large

  1. NTP jitter very large

    I have a very strange problem that started a few days ago. The server
    is running kernel 2.4.28 and has been running for several years
    without any issues.

    When starting the ntp service, the time is initially set correctly
    using ntpdate but after a while, the time will be offset by several
    hours. The longer ntp is allowed to run, the larger the offset appears
    to be. It seems to level off around 6 hours offset.

    When I start NTP and query it at several minute intervals, this is the
    result:

    After initial startup:
    [root@hydra src]# ntpq -p
    remote refid st t when poll reach delay
    offset jitter
    ================================================== ============================
    LOCAL(0) .LOCL. 13 l - 64 1 0.000
    0.000 0.001
    pbx.... . INIT. 16 u - 64 0 0.000
    0.000 0.001

    After 30 seconds:
    remote refid st t when poll reach delay
    offset jitter
    ================================================== ============================
    LOCAL(0) .LOCL. 13 l 24 64 1 0.000
    0.000 0.001
    pbx.... time-a.nist.gov 2 u 23 64 1 0.214
    -702.33 0.001

    After 1 minute:
    remote refid st t when poll reach delay
    offset jitter
    ================================================== ============================
    LOCAL(0) .LOCL. 13 l 2 64 3 0.000
    0.000 0.001
    pbx.... time-a.nist.gov 2 u - 64 3 0.157
    -20590. 19888.0


    This problem occurs whether I initially sync to an internal server or
    NIST directly. The jitter always seems to become very large in a short
    period of time.

    I upgraded from 4.2.0 to 4.2.4b4, but the problem remains. The
    interesting thing to note is that our "pbx" server does not display
    this large jitter and is connected to the same network.

    Does anyone have any suggestions as to why this would be?

    Any assistance would be greatly appreciated.

    Regards,

    Stephan.

  2. Re: NTP jitter very large

    On 2008-06-06, stephan@newace.ca wrote:

    > I have a very strange problem that started a few days ago. The server
    > is running kernel 2.4.28 and has been running for several years
    > without any issues.


    Has anything changed on this system?

    > When starting the ntp service, the time is initially set correctly
    > using ntpdate but after a while, the time will be offset by several
    > hours. The longer ntp is allowed to run, the larger the offset appears
    > to be. It seems to level off around 6 hours offset.


    [snip]

    > After 1 minute:
    > remote refid st t when poll reach delay offset jitter
    >================================================== ===================
    > LOCAL(0) .LOCL. 13 l 2 64 3 0.000 0.000 0.001
    > pbx... time-a.nist.gov 2 u - 64 3 0.157 -20590. 19888.0


    This ntpd is configured to use the Undisciplined Local Clock (or
    LocalCLK) as a fake time source. Doing so is a bad idea unless this
    ntpd needs to serve time to others even when no real time sources are
    available.

    What is most likely happening is this ntpd is syncing to the LocalCLK
    and drifting away from the pbx. Please try running ntpd without the
    LocalCLK and post the results here.

    We need to see your ntpq -p billboard after this ntpd has synced to one
    of those time sources (look for the '*' in the first column) or ~ 20
    minutes, which ever comes first. Please condense the billboard lines as
    I did above.

    > I upgraded from 4.2.0 to 4.2.4b4, but the problem remains. The
    > interesting thing to note is that our "pbx" server does not display
    > this large jitter and is connected to the same network.
    >
    > Does anyone have any suggestions as to why this would be?


    You may want to take a look at the Known Hardware Issues and Known
    Operating System Issues sections of
    http://support.ntp.org/bin/view/Supp...bleshootingNTP to see if
    anything there addresses your problem system.

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

  3. Re: NTP jitter very large

    stephan@newace.ca writes:

    >I have a very strange problem that started a few days ago. The server
    >is running kernel 2.4.28 and has been running for several years
    >without any issues.


    You have LOCAL as a server why? Why in the world would you tell the system
    to use itself as a time source. While this might be useful for a server, it
    is not for a client.



    >When starting the ntp service, the time is initially set correctly
    >using ntpdate but after a while, the time will be offset by several
    >hours. The longer ntp is allowed to run, the larger the offset appears
    >to be. It seems to level off around 6 hours offset.


    >When I start NTP and query it at several minute intervals, this is the
    >result:


    >After initial startup:
    >[root@hydra src]# ntpq -p
    > remote refid st t when poll reach delay
    >offset jitter
    >================================================== ============================
    > LOCAL(0) .LOCL. 13 l - 64 1 0.000
    >0.000 0.001
    > pbx.... . INIT. 16 u - 64 0 0.000
    >0.000 0.001


    >After 30 seconds:
    > remote refid st t when poll reach delay
    >offset jitter
    >================================================== ============================
    > LOCAL(0) .LOCL. 13 l 24 64 1 0.000
    >0.000 0.001
    > pbx.... time-a.nist.gov 2 u 23 64 1 0.214
    >-702.33 0.001


    >After 1 minute:
    > remote refid st t when poll reach delay
    >offset jitter
    >================================================== ============================
    > LOCAL(0) .LOCL. 13 l 2 64 3 0.000
    >0.000 0.001
    > pbx.... time-a.nist.gov 2 u - 64 3 0.157
    >-20590. 19888.0



    >This problem occurs whether I initially sync to an internal server or
    >NIST directly. The jitter always seems to become very large in a short
    >period of time.


    And time-a never becomes the server of reference, not does local.

    So that looks like the natural very high drift of your clock.
    It has lost 13 seconds in 30 sec. That is absolutely impossible for ntp to
    correct, and indicates a HIGHLY defective system clock. Never mind the
    jitter.



    >I upgraded from 4.2.0 to 4.2.4b4, but the problem remains. The
    >interesting thing to note is that our "pbx" server does not display
    >this large jitter and is connected to the same network.


    >Does anyone have any suggestions as to why this would be?


    Your computer clock is completely screwed? Your kernel timer routines are
    seriously defective?


    >Any assistance would be greatly appreciated.


    >Regards,


    >Stephan.


  4. Re: NTP jitter very large

    Steve Kostecke writes:

    >On 2008-06-06, stephan@newace.ca wrote:


    >> I have a very strange problem that started a few days ago. The server
    >> is running kernel 2.4.28 and has been running for several years
    >> without any issues.


    >Has anything changed on this system?


    >> When starting the ntp service, the time is initially set correctly
    >> using ntpdate but after a while, the time will be offset by several
    >> hours. The longer ntp is allowed to run, the larger the offset appears
    >> to be. It seems to level off around 6 hours offset.


    >[snip]


    >> After 1 minute:
    >> remote refid st t when poll reach delay offset jitter
    >>================================================== ===================
    >> LOCAL(0) .LOCL. 13 l 2 64 3 0.000 0.000 0.001
    >> pbx... time-a.nist.gov 2 u - 64 3 0.157 -20590. 19888.0


    >This ntpd is configured to use the Undisciplined Local Clock (or
    >LocalCLK) as a fake time source. Doing so is a bad idea unless this
    >ntpd needs to serve time to others even when no real time sources are
    >available.


    >What is most likely happening is this ntpd is syncing to the LocalCLK
    >and drifting away from the pbx. Please try running ntpd without the
    >LocalCLK and post the results here.


    It cannot. It is driftine at 130000 PPM, which is way way way outside of
    NTP's range.


    >We need to see your ntpq -p billboard after this ntpd has synced to one
    >of those time sources (look for the '*' in the first column) or ~ 20
    >minutes, which ever comes first. Please condense the billboard lines as
    >I did above.


    It will never sync with that kind of drift rate.


    >> I upgraded from 4.2.0 to 4.2.4b4, but the problem remains. The
    >> interesting thing to note is that our "pbx" server does not display
    >> this large jitter and is connected to the same network.
    >>
    >> Does anyone have any suggestions as to why this would be?


    >You may want to take a look at the Known Hardware Issues and Known
    >Operating System Issues sections of
    >http://support.ntp.org/bin/view/Supp...bleshootingNTP to see if
    >anything there addresses your problem system.


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


  5. Re: NTP jitter very large

    stephan@newace.ca wrote:

    > When starting the ntp service, the time is initially set correctly
    > using ntpdate but after a while, the time will be offset by several


    The jitter is the result of the huge offsets, not the other way round.

    > hours. The longer ntp is allowed to run, the larger the offset appears
    > to be. It seems to level off around 6 hours offset.


    You have a very weird mechanism if the system suddenly stops drifting,
    although you maybe have a temperature dependent hardware fault.

    Although your problem is not an ntpd one, I do agree with the comments
    others have made about using the local clock, and would add that, where
    its use is appropriate, you should arrange for it to be outvoted by
    servers that are running with the correct time.

    >


+ Reply to Thread