Koozali.org: home of the SME Server
Obsolete Releases => SME Server 7.x => Topic started by: larieu on December 08, 2008, 03:48:15 PM
-
I have a strange situation
I noticed this from several days ago when I updated all packages installed on server
and I don't know from where to catch the problem
any hint will be welcomed
If I set manually the date and time on server after several minutes (15-20) I can notify that the server go in future
if I let them "to do his job" after 6-8 hours it goes up to 4-6 hour in future
in the past I had the NTP service set to europe.pool.ntp.org
and everything seems to work normall
after I noticed one +10 hour advance of the time on server I changed to several NTP public servers
the behaviour remain the same (my server predict the future)
I tried follwing 2 work around
1. I checked the server settings for the time (It's ok EET with daylight saving)
I set the clock manually by date and wait several minutes
in 5 minutes I was able to observe an 40 s "acceleration per minute"
for example I set 2008 12 08 10 00 00 and after 5 minutes
I had
2008 12 08 18 20 (expected 2008 12 08 15 00)
2. I set
hwclock --set --localtime --date="appropriate date" (for example 2008 12 08 10 00 00" )
after that I set
net time set
wait for 5 minutes
the same +40s per minute was seen
I don't know another approach to this problem
thank you in advance for any comment
-
Is this a hardware server or perhaps a VMWare server?
-
it is not an virtual one
Is one hardware server
based on Intel TM board with 965 chipset
INTEL DQ965GF
the BIOS date is 07/27/2008 v 6079
right now I sow that it exist a new version 01/12/2008 v 6088 on INTEL site
but it will take some time to look on version changing to see if it will help me
I wonder if it exist an way to have a list of all contribs I installed on this server until now
to see if some of them can cause this kind of trouble
-
I wonder if it exist an way to have a list of all contribs I installed on this server until now
to see if some of them can cause this kind of trouble
I doubt if that is the cause, but if you have a recent installation from the 7.x tree you might have the newrpms tool in the audit folder you could run to see what was additionally installed.
Log in as root and observe the output of this command:
/sbin/e-smith/audittools/newrpms
-
this are the packages installed last time
[root@mail ~]# /sbin/e-smith/audittools/newrpms
==============================================================
WARNING: Additional commands may be required after running yum
==============================================================
Loading "installonlyn" plugin
Loading "fastestmirror" plugin
Loading "smeserver" plugin
Setting up repositories
Loading mirror speeds from cached hostfile
Reading repository metadata in from local files
Excluding Packages from CentOS - os
Finished
Excluding Packages from CentOS - updates
Finished
Extra Packages
GeoIP.i386 1.4.4-1.el4.centos installed
fping.i386 2.4-1.b2.2.el4.rf installed
ghostscript-fonts.noarch 6.0-4rvda installed
hddtemp.i386 0.3-0.beta12.2.2.el4.r installed
hylafax.i386 20080423:4.4.4-1.el4.s installed
kernel.i686 2.6.9-67.0.7.EL installed
kernel.i686 2.6.9-67.0.4.EL installed
kernel.i686 2.6.9-67.0.1.EL installed
kernel-smp.i686 2.6.9-67.0.1.EL installed
kernel-smp.i686 2.6.9-67.0.7.EL installed
kernel-smp.i686 2.6.9-67.0.4.EL installed
kronolith-h3.noarch 2.2-1.el4.sme installed
libmcrypt.i386 2.5.7-5.el4 installed
metamail.i386 2.7-28 installed
mnemo-h3.noarch 2.2.1-1.el4.sme installed
monitor-edid.i386 1.11-1.el4.remi installed
nag-h3.noarch 2.2-1.el4.sme installed
ocsinventory-agent.noarch 0.0.6-1.el4.remi installed
ocsinventory-ipdiscover.i386 1.01-2.el4.remi installed
perl-Apache-DBI.noarch 1.07-1.el4 installed
perl-Apache-Htpasswd.noarch 1.8-1.el4.rf installed
perl-Class-Accessor.noarch 0.31-1.el4.rf installed
perl-Config-Tiny.noarch 2.12-1.el4.rf installed
perl-Crypt-DES.i386 2.05-3.2.el4.rf installed
perl-Date-Pcalc.noarch 1.2-1.2.el4.rf installed
perl-Email-Valid.noarch 0.179-1.el4.rf installed
perl-Filesys-DiskFree.noarch 0.06-1.2.el4.rf installed
perl-GD.i386 2.41-2.el4.rf installed
perl-GD-Graph.noarch 1.43-1.2.el4.rf installed
perl-GD-Graph3d.noarch 0.63-2.2.el4.rf installed
perl-GD-Text-Util.noarch 0.86-1.2.el4.rf installed
perl-Geo-IP.i386 1.31-1.el4.centos installed
perl-HTML-Format.noarch 2.04-1.2.el4.rf installed
perl-HTML-Tree.noarch 1:3.23-2.el4 installed
perl-MIME-Lite.noarch 3.01-5.el4 installed
perl-Math-Calc-Units.noarch 1.06-1.el4.rf installed
perl-Net-Jabber.noarch 2.0-1.2.el4.rf installed
perl-Net-SNMP.noarch 5.2.0-1.2.el4.rf installed
perl-Net-XMPP.noarch 1.02-1.el4.rf installed
perl-Params-Validate.i386 0.91-1.el4.rf installed
perl-SOAP-Lite.noarch 0.710.08-1.el4.rf installed
perl-Text-Autoformat.noarch 1.13-1.2.el4.rf installed
perl-Text-Reform.noarch 1.11-1.2.el4.rf installed
perl-Unicode-String.i386 2.09-6.el4 installed
perl-XML-Simple.noarch 2.18-1.el4.rf installed
perl-XML-Stream.noarch 1.22-1.2.el4.rf installed
perl-esmith-PasswordTools.noarch 0.02-2.el4.sme installed
perl-rrdtool.i386 1.2.28-1.el4.rf installed
php-pear-HTTP-Request.noarch 1.4.0-1.el4.sme installed
php-pear-Net-Socket.noarch 1.0.6-1.el4.sme installed
php-pear-Net-URL.noarch 1.0.14-1.el4.sme installed
phpmyadmin.noarch 2.11.9.3-1.el4.rf installed
roundcube.noarch 0.1-479svn.el4.sme installed
rrdtool.i386 1.2.28-1.el4.rf installed
smeserver-certificate.noarch 1.0-1 installed
smeserver-dirty-tools.noarch 0.0.9-2.el4.sme installed
smeserver-gallery2.noarch 2.2-3.el4.sme installed
smeserver-hylafax.noarch 0.9-6.el4.sme installed
smeserver-inventory-tools.i386 1-7.el4.sme installed
smeserver-joomla.noarch 1.5.1-2 installed
smeserver-lazy_admin_tools.noarch 0.9.1-2 installed
smeserver-mailstats.noarch 0.0.3-13.el4.sme installed
smeserver-mnemo.noarch 2.2-2.el4.sme installed
smeserver-mod_python.noarch 0.1-1.el4.sme installed
smeserver-nag.noarch 2.2-1.el4.sme installed
smeserver-nagios.noarch 1.0.5-0 installed
smeserver-nagios-nsca.noarch 1.0.1-0.el4.sme installed
smeserver-phpldapadmin.noarch 0.9.8.3-1.el4.sme installed
smeserver-phpmyadmin.noarch 2.11.1.2-3.el4.sme installed
smeserver-qpsmtpd-spamassassinlevelstars 0.0.2-1.el4.sme installed
smeserver-roundcube.noarch 0.9-7.el4.sme installed
smeserver-saco-qmHandle.noarch 1.3.4-3 installed
smeserver-sitemaker.noarch 2.0.1-3.el4.sme installed
smeserver-system_monitor.noarch 1.1-1 installed
smeserver-teamspeak-server.noarch 2.0.24.1-1.el4.sme installed
smeserver-typo3.noarch 4.1.1-2.el4.sme installed
smeserver-userpanel.noarch 0.9-11.el4.sme installed
smeserver-userpanels.noarch 1.0-22.el4.sme installed
smeserver-vacation.noarch 1.0-30.el4.sme installed
smeserver-wbl.noarch 0.1.0-8.el4.sme installed
smeserver-webshare.noarch 1.0.0-9.el4.sme installed
================================================================
No new rpms were installed. No additional commands are required.
================================================================
-
I do not think it is in the list. To tackle your issues I suggest you launch a bug and attach the output (not post it inline) as well as a little server history and the problems (symptoms) you are experiencing to as much detail as you can.
If you have done so, please post a link to the bug here as reference for future readers.
-
:o And I thought I was the only one....
I noticed the same issue on an 7.4 server with Dutch webinterface (no vm) that I installed just last Saturday.
I don't quite remember if I had set it up initially on ntp sync or manual date/time set, but whatever I try to change from one to the other on the server-manager page it just doesn't work like it is supposed to do.
I even tried doing "/etc/init.d/ntpd stop" but reviewing the output of "ps aux" still shows ntp processes ([ntpd -n -l /dev/stdout] and [runsv ntpd]) although the time is synchronized correctly. Anyhow, this is what happened when I executed the date command after the stop command:
[root@ngtynnym ~]# date
Tue Dec 9 14:40:58 CET 2008
[root@ngtynnym ~]# date
Tue Dec 9 14:40:58 CET 2008
[root@ngtynnym ~]# date
Tue Dec 9 14:40:59 CET 2008
[root@ngtynnym ~]# date
Tue Dec 9 14:41:00 CET 2008
[root@ngtynnym ~]# date
Tue Dec 9 14:40:56 CET 2008
[root@ngtynnym ~]# date
Tue Dec 9 14:40:57 CET 2008
[root@ngtynnym ~]# date
Tue Dec 9 14:40:58 CET 2008
[root@ngtynnym ~]# date
Tue Dec 9 14:40:59 CET 2008
[root@ngtynnym ~]# date
Tue Dec 9 14:41:00 CET 2008
[root@ngtynnym ~]# date
Tue Dec 9 14:40:57 CET 2008
Before the stop command the time was around 7:50am.
Could a workaround be to stop the ntpd process continously so it (apparently) restarts and syncs to the right time?
@larieu: have you already submitted a bug report? I hope this issue is solved soon.
-
@larieu: have you already submitted a bug report? I hope this issue is solved soon.
You don't have to wait for larieu, if you experience the problem you can create a bug report as well. :-)
-
I noticed the same issue on an 7.4 server with Dutch webinterface (no vm) that I installed just last Saturday.
The locale of the server-manager panels should have nothing to do with your timekeeping issues.
I don't quite remember if I had set it up initially on ntp sync or manual date/time set, but whatever I try to change from one to the other on the server-manager page it just doesn't work like it is supposed to do.
AFAIK SME Server comes default with ntpd configured on and listening to smeserver.pool.ntp.org.
I even tried doing "/etc/init.d/ntpd stop" but reviewing the output of "ps aux" still shows ntp processes ([ntpd -n -l /dev/stdout] and [runsv ntpd]) although the time is synchronized correctly.
AFAIK that service is supervised and will restart automatically.
What is the output of ntpq -pn
-
@cactus:
[root@ngtynnym ~]# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
204.9.53.11 .INIT. 16 u - 64 0 0.000 0.000 4000.00
145.24.129.6 .INIT. 16 u - 64 0 0.000 0.000 4000.00
193.193.193.113 .INIT. 16 u - 64 0 0.000 0.000 4000.00
141.35.1.80 .INIT. 16 u - 64 0 0.000 0.000 4000.00
127.127.1.0 LOCAL(0) 10 l - 64 0 0.000 0.000 4000.00
-
[root@ngtynnym ~]# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
204.9.53.11 .INIT. 16 u - 64 0 0.000 0.000 4000.00
145.24.129.6 .INIT. 16 u - 64 0 0.000 0.000 4000.00
193.193.193.113 .INIT. 16 u - 64 0 0.000 0.000 4000.00
141.35.1.80 .INIT. 16 u - 64 0 0.000 0.000 4000.00
127.127.1.0 LOCAL(0) 10 l - 64 0 0.000 0.000 4000.00
Does it keep displaying .INIT. under the refid even after an hour or so? This looks like no connection has been established. Did you do this right after a restart?
Are you sure you did not modify anything to the configuration files for ntpd?
-
Yes sorry about that, I issued the command right after restarting ntpd.
Just checked again:
[root@ngtynnym ~]# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
204.9.53.11 64.202.112.75 2 u 19 64 77 9.168 60925.5 1301049
145.24.129.6 193.79.237.14 2 u 30 64 77 14.044 1943667 1278265
193.193.193.113 192.43.244.18 2 u 226 64 37 53.825 182793. 1095740
141.35.1.80 131.234.137.23 2 u 4 64 77 30.796 1986317 1301785
*127.127.1.0 LOCAL(0) 10 l 11 64 77 0.000 0.000 0.004
[root@ngtynnym ~]# date
Wed Dec 10 08:02:16 CET 2008
Time is really lost again. What does the table tell you? Anyway, I did another:
[root@ngtynnym ~]# /etc/init.d/ntpd stop
Shutting down ntpd: [ OK ]
[root@ngtynnym ~]# date
Wed Dec 10 13:52:43 CET 2008
-
Yes sorry about that, I issued the command right after restarting ntpd.
Just checked again:
[root@ngtynnym ~]# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
204.9.53.11 64.202.112.75 2 u 19 64 77 9.168 60925.5 1301049
145.24.129.6 193.79.237.14 2 u 30 64 77 14.044 1943667 1278265
193.193.193.113 192.43.244.18 2 u 226 64 37 53.825 182793. 1095740
141.35.1.80 131.234.137.23 2 u 4 64 77 30.796 1986317 1301785
*127.127.1.0 LOCAL(0) 10 l 11 64 77 0.000 0.000 0.004
[root@ngtynnym ~]# date
Wed Dec 10 08:02:16 CET 2008
Time is really lost again. What does the table tell you?
It tells me that you are synchronising against four stratum 2 servers, but that the time offset's are way off. Also the jitter, the difference between the result of multiple time queries is very high, most likely due to you trying to stop the service, where SME Server automatically restarts it.
Anyway, I did another:
[root@ngtynnym ~]# /etc/init.d/ntpd stop
Shutting down ntpd: [ OK ]
[root@ngtynnym ~]# date
Wed Dec 10 13:52:43 CET 2008
Stop doing that, as that will bring you no relief as this is a supervised service (which will keep restarting like I explained earlier).
We first need to temporarily disable ntpd:
db configuration setprop ntpd status disabledNow we stop the service:
service ntpd stopNow we can manually sync the clock like this:
ntpdate 0.smeserver.pool.ntp.orgThe output should look something like this (and the offset should be really small), if not try and repeat it a few times to see if the offset gets smaller (I believe ntpd will only adjust to a certain level at once sometimes):
[root@homer ~]# ntpdate 0.smeserver.pool.org
10 Dec 16:36:32 ntpdate[17163]: adjust time server 67.220.194.133 offset -0.003384 sec
[root@homer ~]#Now we should be able to start ntpd again:
db configuration setprop ntpd status enabledAnd firing up the service again:
service ntpd startIt should start OK now, you can check the status like this:
service ntpd statusIf it runs it should look something like this:
[root@homer ~]# service ntpd status
run: /service/ntpd: (pid 17261) 3s, normally down; run: log: (pid 2384) 26338s
[root@homer ~]#
Now after some time do this again to see what the status of the time on your system is:
ntpq -pn
-
First of all, thanks for helping!
I just did what you described, here is result:
[root@ngtynnym ~]# date
Wed Dec 10 14:54:20 CET 2008
[root@ngtynnym ~]# db configuration setprop ntpd status disabled
[root@ngtynnym ~]# service ntpd stop
Stopping ntpd: [ OK ]
[root@ngtynnym ~]# ntpdate 0.smeserver.pool.ntp.org
11 Dec 07:56:25 ntpdate[26829]: step time server 130.89.164.77 offset 61295.620128 sec
[root@ngtynnym ~]# ntpdate 0.smeserver.pool.ntp.org
11 Dec 08:07:11 ntpdate[26853]: step time server 204.9.53.11 offset 609.301594 sec
[root@ngtynnym ~]# ntpdate 0.smeserver.pool.ntp.org
11 Dec 08:08:16 ntpdate[26864]: step time server 204.9.53.11 offset 60.929864 sec
[root@ngtynnym ~]# ntpdate 0.smeserver.pool.ntp.org
11 Dec 08:09:20 ntpdate[26869]: step time server 204.9.53.11 offset 60.930072 sec
[root@ngtynnym ~]# ntpdate 0.smeserver.pool.ntp.org
11 Dec 08:11:30 ntpdate[26877]: step time server 204.9.53.11 offset 121.860101 sec
[root@ngtynnym ~]# date
Thu Dec 11 08:11:30 CET 2008
[root@ngtynnym ~]# ntpdate 0.smeserver.pool.ntp.org
11 Dec 08:12:34 ntpdate[26884]: step time server 204.9.53.11 offset 60.930195 sec
[root@ngtynnym ~]# db configuration setprop ntpd status enabled
[root@ngtynnym ~]# service ntpd start
Starting ntpd: [ OK ]
[root@ngtynnym ~]# service ntpd status
run: /service/ntpd: (pid 26915) 1s, normally down; run: log: (pid 2923) 250663s
I haven't modified files in any way. I just configured everything by means of the server-manager webinterface.
[root@ngtynnym ~]# cat /etc/ntp.conf
#------------------------------------------------------------
# !!DO NOT MODIFY THIS FILE!!
#
# Manual changes will be lost when this file is regenerated.
#
# Please read the developer's guide, which is available
# at http://www.contribs.org/development/
#
# Copyright (C) 1999-2006 Mitel Networks Corporation
#------------------------------------------------------------
server 0.europe.pool.ntp.org
server 1.europe.pool.ntp.org
server 2.europe.pool.ntp.org
server 3.europe.pool.ntp.org
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
driftfile /etc/ntp/drift
I will post again after an hour or so to see what the time is then on this server.
-
Just tried to see what is going on with the RTC
[root@ngtynnym ~]# date
Thu Dec 11 08:14:58 CET 2008
[root@ngtynnym ~]# service ntpd status
run: /service/ntpd: (pid 26915) 146s, normally down; run: log: (pid 2923) 250808s
[root@ngtynnym ~]# date
Thu Dec 11 08:15:20 CET 2008
[root@ngtynnym ~]# hwclock
Thu 11 Dec 2008 08:39:16 AM CET -0.580514 seconds
...........
[root@ngtynnym ~]# date
Thu Dec 11 08:15:32 CET 2008
[root@ngtynnym ~]# hwclock --hctosys
[root@ngtynnym ~]# date
Thu Dec 11 08:42:44 CET 2008
[root@ngtynnym ~]# hwclock
Thu 11 Dec 2008 08:42:48 AM CET -0.849626 seconds
...........
[root@ngtynnym ~]# hwclock
Thu 11 Dec 2008 08:44:49 AM CET -0.984365 seconds
[root@ngtynnym ~]# date
Thu Dec 11 08:44:27 CET 2008
To me it seems the BIOS battery is okay. But why doesn't system time show the same time as RTC?
-
[root@ngtynnym ~]# ntpdate 0.smeserver.pool.ntp.org
11 Dec 08:07:11 ntpdate[26853]: step time server 204.9.53.11 offset 609.301594 sec
[root@ngtynnym ~]# ntpdate 0.smeserver.pool.ntp.org
11 Dec 08:08:16 ntpdate[26864]: step time server 204.9.53.11 offset 60.929864 sec
[root@ngtynnym ~]# ntpdate 0.smeserver.pool.ntp.org
11 Dec 08:09:20 ntpdate[26869]: step time server 204.9.53.11 offset 60.930072 sec
[root@ngtynnym ~]# ntpdate 0.smeserver.pool.ntp.org
11 Dec 08:11:30 ntpdate[26877]: step time server 204.9.53.11 offset 121.860101 sec
[root@ngtynnym ~]# date
Thu Dec 11 08:11:30 CET 2008
Strange, it seems not to get closer than 120s.
I haven't modified files in any way. I just configured everything by means of the server-manager webinterface.
OK.
I will post again after an hour or so to see what the time is then on this server.
I think it is time to report a bug, it might not be fixed by reporting it as a bug but I suspect there is some issue with CPU, motherboard and/or current kernel.
-
I think it is time to report a bug, ...
No, it is long past that time. Please do not try to help people troubleshoot possible bugs here. The bug tracker is the only correct place.
-
No, it is long past that time. Please do not try to help people troubleshoot possible bugs here. The bug tracker is the only correct place.
Sorry :-D
-
based on Intel TM board with 965 chipset
INTEL DQ965GF
just a question: do you have an intel gigabit lan adapter using the e1000 module? If so, try to replace your eth with another one (different chipset)..
Ciao
Stefano
p.s. I know that, as Charlie said, bugzilla is the only place to discuss such a problem, but it could be an hw/kernel issue, so not directly a SME one
-
Well guys and girls,
I really don't have a clue why just now everything just seems fine. I disabled ntp synchronization as per 'cactus' instructions:
[root@ngtynnym ~]# db configuration setprop ntpd status disabled
[root@ngtynnym ~]# service ntpd stop
Then I went ahead and did a manual ntpdate sync; after that hwclock to sync time to the RTC. Finally I rebooted, however, in *nix that's not-done but don't blame me for it. In the webinterface date/time is set to manual as to be expected.
As this system is running in a production environment and the users were without e-mail since last Monday, I will not tinker with it again. Instead I will pull a backup and restore that to another system to see if I can reproduce the error so a bug can be submitted on bugzilla.
Thanks for all the help so far, now the real pain begins.
Cheers,
Edwin
PS. On this system no e1000 but only e100
-
nenonano
yes it is an Gigabit interface
this is how it authenticate in OCS : "Intel Corporation 82566DM Gigabit Network Connection"
unfortunately this server is 2000 Km away from me until in middle of January (I'll go there only after the middle of January :sad:)
the strange thing is that this server worked very well for more than one year
and after last set of updates
the "monitor" start to have big gaps inside (the monitor graphs display only few stripes of data)
I uninstall and tried with the new smeserver-monitor
the same result
after that I noticed the time shift
other issue:
[root@mail ~]# ntpdate 0.smeserver.pool.ntp.org
12 Dec 08:36:28 ntpdate[25248]: the NTP socket is in use, exiting
this is confusing me
I tried with all 0,1,2,3 smeserver, and europe and asia.... the same result
I'll try to make time to raise it as bug (if noone already did it)
please tell me the best practice to see if the bug is already raised?
-
I'll try to make time to raise it as bug (if noone already did it)
please tell me the best practice to see if the bug is already raised?
You would have to look at opened bugs or search for them. I do not think one has already been raised, so please do so in as much relevant detail as you can.
-
please tell me the best practice to see if the bug is already raised?
Just raise a bug. Developers will quickly close it as a duplicate if the problem has already been reported.
-
larieu
2. I set
hwclock --set --localtime --date="appropriate date" (for example 2008 12 08 10 00 00" )
after that I set
net time set
wait for 5 minutes
the same +40s per minute was seen
That is an indication that the RTC (Real Time Clock).... IC (integrated circuit) is not accurate or maintaining accuracy.
A bios update may resolve the issue, however it's not likely.
You could update the bios and recheck the hwclock again.
Also the OS will not be cause for the RTC to be inaccurate, however there are some software that can correct RTC accuracy, it is dependent
on the hardware (motherboard) supporting that capability.
Typical causes for the RTC not maintaining accuracy are due motherboard RTC oscillators not on frequency or drifting (changing frequency).
There are a few electrical components on the motherboard that support the RTC and are involved with the oscillator frequency control and stability.
Most, not all, motherboards use a 32khz watch crystal to control the RTC oscillator, if the crystal is off frequency then the RTC will not maintain accuracy.
If the Motherboard is in warranty then it is suggested you get it swapped out.
If it is out of warranty you will need to have the crystal changed out should your motherboard have the crystal.
I looked for a picture of that MB, but could not locate one that clearly showed the motherboard to see a crystal.
Also Intel doc's do not indicate sufficient info about the RTC circuit to determine if it has a crystal.
Crystal swap out is a delicate repair, so it's not suggested you undertake the repair unless you have the equipment & skill needed.
The crystal is the small can at the top with the two wires in the picture below, you can see how small it is and some are half that size.
(http://www.wrighthobbies.net/examples/RTCcrystal1-sm.jpg)
The actual Frequency of the watch crystal is 32.7680kHz and is divided down by the RTC IC to yield a very precise millisecond time base.
If the actual crystal Frequency is 32.7681kHz then the RTC will run a few seconds faster per minute, doesn't take much of a flaw as one can see.
Here's some additional info on the subject http://www.maxim-ic.com/appnotes.cfm/an_pk/3566 (http://www.maxim-ic.com/appnotes.cfm/an_pk/3566)
These watch crystals are a standard used in electronic digital and analog watches, TV's, VCR's as well as any electronics that includes a clock and of
course computers, along with the RTC IC.
BTW the only time piece that is more stable and accurate then a crystal controlled RTC is an Atomic Clock, which is used at the sites that computers
sync to in most cases and are also used to maintain accuracy on satellites in particular GPS satellites where accuracy is vital in computing your location
as well as maintaining the satellite location and orbit. Also JFYI..... GPS satellites are in Medium Earth Orbits 12,000 miles from earth, TV satalites are are in geosynchronous orbits 23,000 miles from earth.
Here's the concept with TV satellites, the same 5 watts of power or less (the 5 watt power limit for CB radios you may use) and the signal travels 23,000 miles to get to your TV "crystal" clear.
That little piece of electronics (crystal) plays an ever increasing part in all our lives by the millisecond every day.
You can track most any satellite including the ISS here http://www.n2yo.com/ (http://www.n2yo.com/) for those who may be interested.
HTH
-
Also the following....
watch -n .1 ntpq -pn
or
watch -n .1 hwclock
And to watch the status of raid sync in progress
watch -n .1 cat /proc/mdstat
Ctrl-C to exit the above.
I should have also pointed out.....
There are a few electrical components on the motherboard that support the RTC and are involved with the oscillator frequency control and stability.
Although there are other components involved, the most likely to be defective is the crystal, there are capacitors that can be cause of the accuracy problem.
Since your RTC is running it's not likely to be an issue of accuracy since it isn't the major controlling factor and defective RTC IC usually exibit more pronounced problems, i.e. it's not running at all or it's changing the hours per second.
HTH
-
I can not speak for larieu but I know for sure ingtech has no RTC issues as without ntpd sync enabled the clock runs fine, so I do not think there is a hardware issue, I think there might however be a issue between hardware and ntpd somehow.
-
ingtech didn't indicated or offer the proof that larieu did concerning his issue, so I agree with you.
ingtech info is very strange because the minutes are flopping around from what can be seen.
Would be nice to have the results of these commands as far as stability is concerned since they are real time reporting.
watch -n .1 ntpq -pn
or
watch -n .1 hwclock
or
watch -n .1 date
So far, servers here didn't indicate any issue's with any of the above.
I would think if it was a bug there would be more reports of this issue.
Then again time may be a factor in the event it's a new issue just being discovered.
Wonder how many of us even check the server time regularly.
My membership is.... set it and forget it, as well as the other club, "It just works"
Since I appear now to be a new member of the check it club, this is what we get here.
watch -n .1 ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*129.6.15.28 .ACTS. 1 u 121 1024 377 36.933 2.209 5.106
127.127.1.0 LOCAL(0) 10 l - 64 377 0.000 0.000 0.004
-
For what it's worth, there's a Centos 4.7 bug about severe clock drift with kernel version 2.6.9-78 (the current version on my up-to-date 7.4 SME Server).
Booting with an older kernel seems to get the clock working again.
http://bugs.centos.org/view.php?id=3149, passed to bugzilla.redhat.com as Bug 468697
-
http://bugs.centos.org/view.php?id=3149, passed to bugzilla.redhat.com as Bug 468697
Thanks, so it might even be an upstream issue.
-
For what it's worth, there's a Centos 4.7 bug about severe clock drift with kernel version 2.6.9-78 (the current version on my up-to-date 7.4 SME Server).
Current kernel version is 2.6.9-78.0.8.EL, not 2.6.9-78.
-
1) Check the NTP variables
config show ntpd
2) Update the "Time Zone" Data package.
yum -y update tzdata
3) If you've changed the NTP Server
signal-event timeserver-update
4) If you've changed time zone
signal-event timezone-update
5) signal-event post-upgrade; signal-event reboot
-
Bug#: 4798 refers
-
Thanks to all
sorry for my late reply but I was away for several days for some job duty
between the time I checked also the "hardware issue"
when I upgraded that server (over one year ago) I used one of the 5 MB from the same batch of acquisitions
as I have another 4 identical hardware I asked one of the people there to "change" the MB from the server with one of one computer which works very well in windows environment
the result was: the same time shift is seen
as I saw in some of the previous posts - the issue it is a kernel problem
because the server is far away from me - for the moment I had an crontab which adjust the time each 20 minutes (server time - this is ok if the time on server run faster than the real time)
I'll change the server MB in January when I'll have the scheduled trip for maintenance there
this raise another problem for me
while I use only Intel TM MB (I buy at least 2 for one server - and one is used into an "normal computer" in the same location - this give me "spare parts on site" easy to be replaced by non so technical people)
can you tell me a good choice from the actual offer of intel products
which replace my "problematic" MB
-
I had the same issue with a DG965RY Intel Board which I swapped out for a DG915 board and the issue disappeared. The DG945 are OK too. Don't use a DG946 board with SME at all.
Intel 965 has a suspicious frequency here ..