NNTP server causing large jumps in time - NTP

This is a discussion on NNTP server causing large jumps in time - NTP ; David Woolley wrote: > Dave wrote: >> Looking at the logs on my Sun Blade 2000 running Solaris 10, I see >> numerous occasions on which the time has been stepped. Looking at the >> few only (today, 1/5/2008), I ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 23 of 23

Thread: NNTP server causing large jumps in time

  1. Re: NNTP server causing large jumps in time

    David Woolley wrote:
    > Dave wrote:
    >> Looking at the logs on my Sun Blade 2000 running Solaris 10, I see
    >> numerous occasions on which the time has been stepped. Looking at the
    >> few only (today, 1/5/2008), I see it was stepped around +0.3 sec at 3
    >> AM, then -0.4 at 4:30 am, then half an hour later at 5am it was moved
    >> -0.6 sec, then 40 minutes later it is moved another -0.6 sec. Since
    >> then (its now 1:30 pm), it has not changed.

    >
    > Positive and negative steps which approximately balance each other
    > indicate a heavily loaded link with variable and asymmetric propagation
    > delays. Apart from local servers, or your Rubidium PPS, or reducing the
    > traffic, the other solutions are to apply and get the ISP to apply
    > traffic shaping to prioritise NTP traffic, or to use the tinker huff and
    > puff option, noting the health warnings attached to it.



    I've changed to local servers as suggested

    server 0.uk.pool.ntp.org
    server 1.uk.pool.ntp.org
    server 2.uk.pool.ntp.org
    server 3.uk.pool.ntp.org


    broadcast 224.0.1.1 ttl 0


    statistics loopstats
    statistics peerstats
    driftfile /var/ntp/ntp.drift
    statsdir /var/ntp/ntpstats/
    logconfig =all


    and it has made no significnat difference. (I've just added the lines

    statistics loopstats
    statistics peerstats

    but these were not in the config file when I collected this data.

    May 6 06:11:09 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
    reset (step) 0.224887 s
    May 6 06:38:22 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
    reset (step) 0.669705 s
    May 6 07:18:42 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
    reset (step) 0.253622 s
    May 6 07:47:00 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
    reset (step) 0.405924 s
    May 6 08:39:43 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
    reset (step) -0.277034 s
    May 6 09:13:53 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
    reset (step) 0.144278 s
    May 6 11:10:18 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
    reset (step) 0.487560 s
    May 6 13:58:14 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
    reset (step) 0.150888 s
    May 6 15:02:22 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
    reset (step) -0.243454 s
    May 6 16:03:35 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
    reset (step) -0.284934 s
    May 6 21:35:00 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
    reset (step) -0.369864 s
    May 6 22:39:50 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
    reset (step) -0.396888 s


    After added the lines

    statistics loopstats
    statistics peerstats

    I stopped and started the deamon (I guess refreshing might do), and get:

    May 7 08:35:14 kestrel ntpdate[24721]: [ID 558275 daemon.notice] adjust
    time server 78.129.142.80 offset -0.002180 sec



  2. Re: NNTP server causing large jumps in time

    Dave wrote:
    > David Woolley wrote:
    >> Dave wrote:
    >>> Looking at the logs on my Sun Blade 2000 running Solaris 10, I see
    >>> numerous occasions on which the time has been stepped. Looking at the
    >>> few only (today, 1/5/2008), I see it was stepped around +0.3 sec at 3
    >>> AM, then -0.4 at 4:30 am, then half an hour later at 5am it was moved
    >>> -0.6 sec, then 40 minutes later it is moved another -0.6 sec. Since
    >>> then (its now 1:30 pm), it has not changed.

    >>
    >> Positive and negative steps which approximately balance each other
    >> indicate a heavily loaded link with variable and asymmetric
    >> propagation delays. Apart from local servers, or your Rubidium PPS,
    >> or reducing the traffic, the other solutions are to apply and get the
    >> ISP to apply traffic shaping to prioritise NTP traffic, or to use the
    >> tinker huff and puff option, noting the health warnings attached to it.

    >
    >
    > I've changed to local servers as suggested
    >
    > server 0.uk.pool.ntp.org
    > server 1.uk.pool.ntp.org
    > server 2.uk.pool.ntp.org
    > server 3.uk.pool.ntp.org


    I meant to add that perhaps an overloaded network is the problem. The
    machine only has a 256 kb/s uplink (1024 kb/s downlink), and is used as
    a web server for a small number of little used domains. Perhaps this is
    putting too much strain on it. I occasionally download large files (like
    iso images of Solaris), so I'll check if things get worst next time I do
    that.

  3. Re: NNTP server causing large jumps in time

    Dave wrote:
    > David Woolley wrote:

    ositive and negative steps which approximately balance each other
    >> indicate a heavily loaded link with variable and asymmetric
    >> propagation delays. Apart from local servers, or your Rubidium PPS,
    >> or reducing the traffic, the other solutions are to apply and get the
    >> ISP to apply traffic shaping to prioritise NTP traffic, or to use the
    >> tinker huff and puff option, noting the health warnings attached to it.

    >
    >
    > I've changed to local servers as suggested


    That wasn't my suggestion. The usual location of the problem with
    balanced positive and negative steps is the link to your ISP, so using
    UK servers wouldn't make a difference.

    You've actually got runs of positive and negative steps, which is
    worrying. Normally pure runs of postive steps indicate a lost interrupt
    problem. Runs in a consistent direction and of similar size and
    interval generally indicate that something else is trying to discipline
    the clock. Alternating steps in positive and negative directions tends
    to indicate an overloaded, asymmetric link, but if you have a severe
    problem you tend to have the server rejected (which is why the problem
    is less common with analogue modems), rather than accumulating a large
    correction.

    Missed interrupts may be a problem if runs last long enough for ntpd to
    adapt to the new, effective, frequency.

    >
    > server 0.uk.pool.ntp.org
    > server 1.uk.pool.ntp.org
    > server 2.uk.pool.ntp.org
    > server 3.uk.pool.ntp.org
    >


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2