Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 23

Thread: Workstation time falling behind

  1. #11
    Tilman Schmidt NNTP User

    Default Re: Workstation time falling behind

    L R Nix schrieb:
    > the ntp time setter/checker doesn't check ALL the time. It checks when it
    > starts, then waits a few hours and checks again. If you'll leave the
    > machine, it'll fix itself over time (irony there).


    Not quite. The NTP startup script is supposed to forcibly set the system
    clock to the time of the reference time server once, and then start the
    actual NTP daemon which checks and adjusts the clock periodically,
    adapting the intervals dynamically to achieve maximum stability. But it
    never waits "a few hours": it starts out with an interval of 64 seconds
    (a bit over a minute), and if the clock appears to be quite stable, will
    double that interval repeatedly until it reaches 1024 seconds, or about
    17 minutes. It will not increase further. (Unless you tweak the
    configuration to tell it that it should.)

    HTH
    T.

  2. #12
    Tilman Schmidt NNTP User

    Default Re: Workstation time falling behind

    South African Librarian schrieb:
    > NTP was disabled
    >
    > First thing I did was to enable it. Our Smoothie is on 192.168.zzz.254


    It doesn't serve any useful purpose to hide the third octet of your
    private IP address range from the world - even if you didn't reveal
    it in your logfile excerpt later. :-p

    > - *and it did update the time* although the ntp configuration in the
    > date and time application took ages to do its stuff.


    I'm not sure I understand what you are trying to tell with that sentence.
    What did you do to enable NTP? Did the system time change the moment you
    enabled it? Did it stay synchronized with your time server (ie., not
    drift like before) after that? What is that "date and time application"
    and how long were these ages?

    > Then I rebooted, set the time an hour or so in advance (in the CMOS


    Hmmm. An hour is a hell of a lot of time difference. Normally the NTP
    daemon, seeing such a big difference, will conclude that there is
    something fundamentally wrong with the clock and refrain from trying
    to adjust it. But it shouldn't matter because the NTP startup script
    will do a single hard clock setting before starting the daemon.

    > ntp.conf :

    [comments snipped]
    > server 127.127.1.0
    > fudge 127.127.1.0 stratum 10
    > driftfile /var/lib/ntp/drift/ntp.drift
    > logfile /var/log/ntp
    > keys /etc/ntp.keys
    > trustedkey 1
    > requestkey 1
    > server 192.168.xxx.254


    That looks ok, provided the real value on that last line is the correct
    IP address of your NTP server.

    > suse:/etc # /usr/sbin/ntpq -p
    > remote refid st t when poll reach delay offset jitter
    > ==============================================================================
    > LOCAL(0) .LOCL. 10 l 9 64 3 0.000 0.000 3.906
    > smoothwall 43.142.223.255 2 u 5 64 3 3.906 -142663 4544.53
    > suse:/etc #


    That means that (a) the NTP daemon can indeed reach the NTP time server
    on your Smoothie, (b) the initial timesetting seems to have worked (the
    time difference of -142663 milliseconds, or a bit over 2 minutes, is
    significantly less than the hour of difference you set), and (c) you
    didn't wait long enough by far for the synchronization to converge,
    because at a polling interval of 64 seconds the daemon has only been
    able to contact the time server twice since it was started.

    > /var/log/ntp
    >
    > 22 Aug 10:29:51 ntpd[3107]: Deleting interface #2 lo, ::1#123, interface stats: received=0, sent=0, dropped=0, active_time=1 secs
    > 22 Aug 10:29:51 ntpd[3107]: Deleting interface #3 eth0, fe80::20c:76ff:feaf:269f#123, interface stats: received=0, sent=0, dropped=0, active_time=1 secs
    > 22 Aug 10:29:54 ntpd[3107]: ntpd exiting on signal 15
    > 22 Aug 10:33:06 ntpd[3166]: synchronized to LOCAL(0), stratum 10
    > 22 Aug 10:33:06 ntpd[3166]: time slew +0.000000 s
    > 22 Aug 10:33:07 ntpd[3727]: Deleting interface #2 lo, ::1#123, interface stats: received=0, sent=0, dropped=0, active_time=1 secs
    > 22 Aug 10:33:07 ntpd[3727]: Deleting interface #3 eth0, fe80::20c:76ff:feaf:269f#123, interface stats: received=0, sent=0, dropped=0, active_time=1 secs
    > 22 Aug 10:33:19 ntpd[3727]: ntpd exiting on signal 15
    > 22 Aug 09:02:40 ntpd[3801]: synchronized to LOCAL(0), stratum 10
    > 22 Aug 09:02:40 ntpd[3801]: time slew +0.000000 s
    > 22 Aug 09:02:40 ntpd[3890]: ntpd exiting on signal 15
    > 22 Aug 09:05:56 ntpd[3946]: synchronized to LOCAL(0), stratum 10
    > 22 Aug 09:05:56 ntpd[3946]: time slew +0.000000 s
    > 22 Aug 09:05:57 ntpd[4058]: Deleting interface #2 lo, ::1#123, interface stats: received=0, sent=0, dropped=0, active_time=1 secs
    > 22 Aug 09:05:57 ntpd[4058]: Deleting interface #3 eth0, fe80::20c:76ff:feaf:269f#123, interface stats: received=0, sent=0, dropped=0, active_time=1 secs
    > 22 Aug 09:07:33 ntpd[4058]: ntpd exiting on signal 15
    > 22 Aug 13:11:41 ntpd[2288]: synchronized to LOCAL(0), stratum 10
    > 22 Aug 13:11:41 ntpd[2288]: time slew +0.000000 s
    > 22 Aug 13:11:42 ntpd[2746]: Deleting interface #2 lo, ::1#123, interface stats: received=0, sent=0, dropped=0, active_time=1 secs
    > 22 Aug 13:11:42 ntpd[2746]: Deleting interface #3 eth0, fe80::20c:76ff:feaf:269f#123, interface stats: received=0, sent=0, dropped=0, active_time=1 secs


    Looks all fine to me except the NTP daemon never seems to get a chance
    to run long enough to actually achieve synchronization to its external
    time source. Mine takes about five minutes from the "Deleting interface"
    lines until it displays

    15 Aug 19:28:46 ntpd[4145]: synchronized to 192.168.46.1, stratum 2

    and from then on the clock is rock solid.

    > /var/log/messages


    Looks fine too.

    Next steps I'd propose:

    - Let the daemon run for a few (say, 10) minutes and then to
    "/usr/sbin/ntpq -p" again. If it outputs something like

    remote refid st t when poll reach delay offset jitter
    ==============================================================================
    LOCAL(0) .LOCL. 10 l 45 64 377 0.000 0.000 0.001
    *smoothwall 43.142.223.255 2 u 5 1024 377 74.658 -47.882 18.198

    (specifically, the asterisk before "smoothwall" and the value 377
    in the "reach" column) then all is working fine. Your clock is
    synchronized. If not:

    - Try the command "/etc/init.d/ntp status". It should display

    Checking for network time protocol daemon (NTPD): running

    with the word "running" appearing in green. If not:

    - Try the command "/etc/init.d/ntp start" and report the exact
    result here. Wait 10 minutes, run "/usr/sbin/ntpq -p" again
    and report its result here, too.

    > I will try ab@novell.com's crontab idea out in the meantime.


    If you can live with a system clock that jumps a few seconds to or
    fro once a minute, by all means do.

    HTH
    T.

  3. #13

    Default Re: Workstation time falling behind

    Hi all

    Back at work again.

    Let's get started again :

    I started the PC up last week, and the time is out by 10 minutes as of today.

    As per the previous request, I executed a couple of commands, and pasted their output here :

    output of /etc/init.d/ntp status
    Code:
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    *LOCAL(0)        .LOCL.          10 l   14   64  377    0.000    0.000   3.906
     sabela.saix.net 193.67.79.202    2 u  381 1024  377   16.924  664495. 2613.28
     induna.saix.net 193.67.79.202    2 u  400 1024  377   23.639  664456. 2718.25
    
    Checking for network time protocol daemon (NTPD): running
    After that I executed /etc/init.d/ntp start
    Code:
    Starting network time protocol daemon (NTPD)                         done
    I waited for 10 minutes, but the NTP daemon did not adjust the time automatically.

    Then, after the 10 minutes, I executed /usr/sbin/ntpq -p
    Code:
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    *LOCAL(0)        .LOCL.          10 l   52   64  377    0.000    0.000   3.906
     sabela.saix.net 193.67.79.202    2 u  423 1024  377   16.464  667286. 2791.65
     induna.saix.net 193.67.79.202    2 u  440 1024  377   14.926  667232. 2775.91
    Regards

    Libs

  4. #14
    Join Date
    Jun 2008
    Location
    UTC+10
    Posts
    9,686
    Blog Entries
    4

    Default Re: Workstation time falling behind

    In /etc/sysconfig/ntp, try setting this to yes instead of no which is the default.

    Code:
    # When ntpd is running, the kernel automatically updates CMOS every 13 minutes
    # to match the system time. However, the updates can only work when time is off
    # by less than +-15 minutes. There are machines that don't keep the time all
    # that well when turned off. If you run one of those you can have ntp set
    # the CMOS clock after setting the initial date with ntpdate
    #
    NTPD_ADJUST_CMOS_CLOCK="no"
    Then restart the ntp server and see if it adjusts the clock to match an external server. If not, run this manually:

    Code:
    /usr/sbin/ntpdate -bu ntp.pool.ntp.org
    to get it in sync first.

  5. #15

    Default Re: Workstation time falling behind

    Thanks!

    Will monitor it and see if it loses time again.

    Regards

    Libs

  6. #16
    Join Date
    Jun 2008
    Location
    Canada
    Posts
    52

    Default Re: Workstation time falling behind

    you need to replace the battery on the mobo.

  7. #17
    Join Date
    Jun 2008
    Location
    UTC+10
    Posts
    9,686
    Blog Entries
    4

    Default Re: Workstation time falling behind

    Sorry noticed a typo in my post, not

    /usr/sbin/ntpdate -bu ntp.pool.ntp.org

    but

    /usr/sbin/ntpdate -bu pool.ntp.org

  8. #18

    Default Re: Workstation time falling behind

    Quote Originally Posted by ken_yap View Post
    Sorry noticed a typo in my post, not

    /usr/sbin/ntpdate -bu ntp.pool.ntp.org

    but

    /usr/sbin/ntpdate -bu pool.ntp.org

    Sorry about that, I also encountered the problem, and fixed it on my own - then completely forgot about posting back

    Anyway, it did not help - the time is still falling back...

  9. #19
    Join Date
    Jun 2008
    Location
    UTC+10
    Posts
    9,686
    Blog Entries
    4

    Default Re: Workstation time falling behind

    Could be your workstation is losing timer interrupts. In my case it happens when I do a high-speed burn on the DVD writer. If there are messages in /var/log/messages about that, maybe it's the cause. No idea what you can do about this sort of problem.. Strange though that ntpd cannot keep it in sync. I have an hourly ntpdate job like what I showed that resyncs the clock anyway.

  10. #20
    Join Date
    Jun 2008
    Location
    UTC+10
    Posts
    9,686
    Blog Entries
    4

    Default Re: Workstation time falling behind

    Hmm, I realised we haven't checked for /etc/adjtime yet. This is a file that contains adjustments to the system clock. If it contains insane values it will make the system clock run very oddly. Please do:

    Code:
    cat /etc/adjtime
    and post the values, if the file exists. Then delete the file, resync your workstation and see how it goes.

    The meaning of the values in this file are explained in man hwclock.

Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •