Workstation time falling behind

Hi there

I’ve installed OpenSuSE 11.0 on a motherboard that was lying around, but it seems that this specific motherboard’s clock is slow as the system loses time.

Is there any way that I can get the NTP daemon to run every hour to keep it close to the correct time? (I will use my smoothwall as it’s also a time server so overloading the time server won’t be an issue). >:)

I’ve played around with the NTP settings, but it doesn’t work to my satisfaction as it seems to update the time on bootup only.

Regards

Libs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

True, the time isn’t “slammed” regularly so if the time drifts more-than
1,000 seconds between polls NTP will not update to protect it from an
erroneous time server. Worst-case scenario you can create a cron job.
As root run ‘crontab -e’ and then enter a linen like the following:

0 * * * * ntpdate -u <timeServerIPAddress> 2>/dev/null 1>&2

If you’re drifting by that much, though, you probably want to run this
more often so you don’t have huge jumps in time every hour… NTP is
really lightweight so every couple minutes or even every minute should
be fine unless you have hundreds-of-thousands of boxes.

Good luck.

South African Librarian wrote:
> Hi there
>
> I’ve installed OpenSuSE 11.0 on a motherboard that was lying around,
> but it seems that this specific motherboard’s clock is slow as the
> system loses time.
>
> Is there any way that I can get the NTP daemon to run every hour to
> keep it close to the correct time? (I will use my smoothwall as it’s
> also a time server so overloading the time server won’t be an issue).
>> :slight_smile:
>
> I’ve played around with the NTP settings, but it doesn’t work to my
> satisfaction as it seems to update the time on bootup only.
>
> Regards
>
> Libs
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIrYSr3s42bA80+9kRAtUTAJ9rmQbHgU+axODCngwJ4JPAMlQlLgCfTIN3
vHE4BjrYg9MOmtYIiZ1OiFM=
=3zkx
-----END PGP SIGNATURE-----

Thank you for the quick reply.

I will try this definitely out.

Regards

Libs

South African Librarian schrieb:
> I’ve installed OpenSuSE 11.0 on a motherboard that was lying around,
> but it seems that this specific motherboard’s clock is slow as the
> system loses time.
>
> Is there any way that I can get the NTP daemon to run every hour to
> keep it close to the correct time? (I will use my smoothwall as it’s
> also a time server so overloading the time server won’t be an issue).
>> :slight_smile:
>
> I’ve played around with the NTP settings, but it doesn’t work to my
> satisfaction as it seems to update the time on bootup only.

NTP is designed to run continually, keeping your clock in close sync
(milliseconds) with that of your timeserver. If it updates only once
on boot then something is seriously wrong.

Is the NTP daemon getting started correctly on bootup, ie. is the line
“Starting network time protocol daemon (NTPD)” appearing on your
bootup screen, followed by a green “done”? Does it really update the
clock from the time server on boot, or perhaps just from the system’s
own Real Time Clock (RTC) chip? What is the content of your /etc/ntp.conf
file? What does the command “/usr/sbin/ntpq -p” say? What does the NTP
logfile, /var/log/ntp contain?

HTH
T.

On Thu, 21 Aug 2008 09:56:01 GMT
South African Librarian <South_African_Librarian@no-mx.forums.opensuse.org>
wrote:

>
> Hi there
>
> I’ve installed OpenSuSE 11.0 on a motherboard that was lying around,
> but it seems that this specific motherboard’s clock is slow as the
> system loses time.
>
> Is there any way that I can get the NTP daemon to run every hour to
> keep it close to the correct time? (I will use my smoothwall as it’s
> also a time server so overloading the time server won’t be an issue).
> >:)
>
> I’ve played around with the NTP settings, but it doesn’t work to my
> satisfaction as it seems to update the time on bootup only.
>
> Regards
>
> Libs
>
>

Try the ‘nohz=off’ option on the boot options line at boot-time and through
grub. The new ‘nohz’ mode of the kernel can cause some machines to lose time.

The various NTP responses are also very valid, as even the best machines drop
a tick here and there causing slow drift. Setting up the ntp client service
through YaST -> Network services is a good idea.

Loni


L R Nix
lornix@lornix.com
What time is it? Now? … Now? … Now?

Ok, I’ve played around a bit.

NTP was disabled :o

First thing I did was to enable it. Our Smoothie is on 192.168.zzz.254 - and it did update the time although the ntp configuration in the date and time application took ages to do its stuff.

Then I rebooted, set the time an hour or so in advance (in the CMOS setup), and monitored the clock. I saw no line “Starting network time protocol daemon” scrolling past, but I did gather the rest of the information as requested : (The time did not update)

ntp.conf :


################################################################################
## /etc/ntp.conf
##
## Sample NTP configuration file.
## See package 'ntp-doc' for documentation, Mini-HOWTO and FAQ.
## Copyright (c) 1998 S.u.S.E. GmbH Fuerth, Germany.
##
## Author: Michael Andres,  <ma@suse.de>
##         Michael Skibbe,  <mskibbe@suse.de>
##
################################################################################

##
## Radio and modem clocks by convention have addresses in the
## form 127.127.t.u, where t is the clock type and u is a unit
## number in the range 0-3.
##
## Most of these clocks require support in the form of a
## serial port or special bus peripheral. The particular
## device is normally specified by adding a soft link
## /dev/device-u to the particular hardware device involved,
## where u correspond to the unit number above.
##
## Generic DCF77 clock on serial port (Conrad DCF77)
## Address:     127.127.8.u
## Serial Port: /dev/refclock-u
##
## (create soft link /dev/refclock-0 to the particular ttyS?)
##
# server 127.127.8.0 mode 5 prefer

##
## Undisciplined Local Clock. This is a fake driver intended for backup
## and when no outside source of synchronized time is available.
##
server 127.127.1.0
# local clock (LCL)
fudge 127.127.1.0  stratum 10
# LCL is unsynchronized

##
## Add external Servers using
## # rcntp addserver <yourserver>
##

##
## Miscellaneous stuff
##

driftfile /var/lib/ntp/drift/ntp.drift
# path for drift file

logfile /var/log/ntp
# alternate log file
# logconfig =syncstatus + sysevents
# logconfig =all

# statsdir /tmp/                # directory for statistics files
# filegen peerstats  file peerstats  type day enable
# filegen loopstats  file loopstats  type day enable
# filegen clockstats file clockstats type day enable

#
# Authentication stuff
#
keys /etc/ntp.keys
# path for keys file
trustedkey 1
# define trusted keys
requestkey 1
server 192.168.xxx.254
# key (7) for accessing server variables
# controlkey 15                 # key (6) for accessing server variables

Output of /usr/sbin/ntpq -p


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 #

/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

/var/log/messages


Aug 22 13:11:41 emil ntpd[2745]: ntpd 4.2.4p4@1.1520-o Fri Jun  6 22:53:32 UTC 2008 (1)
Aug 22 13:11:41 emil ntpd[2746]: precision = 4000.000 usec
Aug 22 13:11:41 emil ntpd[2746]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
Aug 22 13:11:41 emil ntpd[2746]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Aug 22 13:11:41 emil ntpd[2746]: Listening on interface #1 wildcard, ::#123 Disabled
Aug 22 13:11:41 emil ntpd[2746]: Listening on interface #2 lo, ::1#123 Enabled
Aug 22 13:11:41 emil ntpd[2746]: Listening on interface #3 eth0, fe80::20c:76ff:feaf:269f#123 Enabled
Aug 22 13:11:41 emil ntpd[2746]: Listening on interface #4 lo, 127.0.0.1#123 Enabled
Aug 22 13:11:41 emil ntpd[2746]: Listening on interface #5 lo, 127.0.0.2#123 Enabled
Aug 22 13:11:41 emil ntpd[2746]: Listening on interface #6 eth0, 192.168.50.242#123 Enabled
Aug 22 13:11:41 emil ntpd[2746]: kernel time sync status 0040
Aug 22 13:11:41 emil ntpd[2746]: frequency initialized 0.000 PPM from /var/lib/ntp/drift/ntp.drift

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

Regards

Libs

No luck with your suggestions either :frowning:

But thanks for your help!

Regards

Libs

> Then I rebooted, set the time an hour or so in advance (in the CMOS
> setup), and monitored the clock… (The time did not update)

just as a “for fun experiment”, set the time within 2 or 3 minutes…


DenverD (Linux Counter 282315) via NNTP, Thunderbird 2.0.0.14, KDE
3.5.7, SUSE Linux 10.3, 2.6.22.18-0.2-default #1 SMP i686 athlon

OK guys

I’ve gone through all your suggestions, and none helped.

I’m trying out public NTP servers from pool.ntp.org and will see if that helps.

The firewall is disabled on this installation.

Regards

Libs

On Fri, 22 Aug 2008 09:16:02 GMT
South African Librarian <South_African_Librarian@no-mx.forums.opensuse.org>
wrote:

>
> OK guys
>
> I’ve gone through all your suggestions, and none helped.
>
> Set the time 2 minutes in advance, and it still is 2 minutes in
> advance. :confused:
>
> I’ve noticed that when I play around with the NTP settings in Yast -
> Network Services is that it the time is updated- but it does not always
> happen, and the application seem to hang.
>
> When I use the option “Use random servers from pool.ntp.org” it take a
> long time, but replies with the server is reachable, but still the time
> is not adjusted. On the smoothwall ports 37 and 123 is open.
>
> The firewall is disabled on this installation.
>
> Regards
>
> Libs
>
>

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).

Loni


L R Nix
lornix@lornix.com
A watched pot never boils…

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.

South African Librarian schrieb:
> NTP was disabled :o
>
> 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.

Hi all

Back at work again. :slight_smile:

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


     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


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


     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

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

# 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:

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

to get it in sync first.

Thanks!

Will monitor it and see if it loses time again.

Regards

Libs

you need to replace the battery on the mobo.

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 rotfl!

Anyway, it did not help - the time is still falling back… >:(

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.

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:

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.