Koozali.org: home of the SME Server

Date go creazy

Offline cactus

  • *
  • 4,880
  • +3/-0
    • http://www.snetram.nl
Re: Date go creazy
« Reply #15 on: December 11, 2008, 09:08:35 AM »
Code: [Select]
[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.
Be careful whose advice you buy, but be patient with those who supply it. Advice is a form of nostalgia, dispensing it is a way of fishing the past from the disposal, wiping it off, painting over the ugly parts and recycling it for more than its worth ~ Baz Luhrmann - Everybody's Free (To Wear Sunscreen)

Offline CharlieBrady

  • *
  • 6,918
  • +3/-0
Re: Date go creazy
« Reply #16 on: December 11, 2008, 12:19:30 PM »
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.

Offline cactus

  • *
  • 4,880
  • +3/-0
    • http://www.snetram.nl
Re: Date go creazy
« Reply #17 on: December 11, 2008, 12:24:00 PM »
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
Be careful whose advice you buy, but be patient with those who supply it. Advice is a form of nostalgia, dispensing it is a way of fishing the past from the disposal, wiping it off, painting over the ugly parts and recycling it for more than its worth ~ Baz Luhrmann - Everybody's Free (To Wear Sunscreen)

Offline Stefano

  • *
  • 10,894
  • +3/-0
Re: Date go creazy
« Reply #18 on: December 11, 2008, 12:31:11 PM »
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

Offline ingtech

  • *
  • 6
  • +0/-0
    • ingTECH
Re: Date go creazy
« Reply #19 on: December 11, 2008, 03:21:11 PM »
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
« Last Edit: December 11, 2008, 03:23:57 PM by ingtech »

Offline larieu

  • *****
  • 214
  • +0/-0
Re: Date go creazy
« Reply #20 on: December 12, 2008, 07:50:26 AM »
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:

Code: [Select]
[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?
« Last Edit: December 12, 2008, 07:52:47 AM by larieu »
if everybody's life around you is better, probably yours will be better
just try to improve their life

Offline cactus

  • *
  • 4,880
  • +3/-0
    • http://www.snetram.nl
Re: Date go creazy
« Reply #21 on: December 12, 2008, 08:39:54 AM »
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.
Be careful whose advice you buy, but be patient with those who supply it. Advice is a form of nostalgia, dispensing it is a way of fishing the past from the disposal, wiping it off, painting over the ugly parts and recycling it for more than its worth ~ Baz Luhrmann - Everybody's Free (To Wear Sunscreen)

Offline CharlieBrady

  • *
  • 6,918
  • +3/-0
Re: Date go creazy
« Reply #22 on: December 12, 2008, 08:42:09 AM »
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.

Offline electroman00

  • *****
  • 491
  • +0/-0
Re: Date go creazy
« Reply #23 on: December 13, 2008, 04:55:04 PM »
larieu
Quote
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.


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

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/ for those who may be interested.

HTH
« Last Edit: December 13, 2008, 05:43:13 PM by electroman00 »

Offline electroman00

  • *****
  • 491
  • +0/-0
Re: Date go creazy
« Reply #24 on: December 13, 2008, 05:27:05 PM »
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.....
Quote
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


« Last Edit: December 13, 2008, 05:29:29 PM by electroman00 »

Offline cactus

  • *
  • 4,880
  • +3/-0
    • http://www.snetram.nl
Re: Date go creazy
« Reply #25 on: December 13, 2008, 05:42:36 PM »
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.
Be careful whose advice you buy, but be patient with those who supply it. Advice is a form of nostalgia, dispensing it is a way of fishing the past from the disposal, wiping it off, painting over the ugly parts and recycling it for more than its worth ~ Baz Luhrmann - Everybody's Free (To Wear Sunscreen)

Offline electroman00

  • *****
  • 491
  • +0/-0
Re: Date go creazy
« Reply #26 on: December 13, 2008, 06:35:08 PM »
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

Offline mmccarn

  • *
  • 2,657
  • +10/-0
Re: Date go creazy
« Reply #27 on: December 14, 2008, 04:29:13 AM »
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

Offline cactus

  • *
  • 4,880
  • +3/-0
    • http://www.snetram.nl
Re: Date go creazy
« Reply #28 on: December 14, 2008, 09:12:08 AM »
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.
Be careful whose advice you buy, but be patient with those who supply it. Advice is a form of nostalgia, dispensing it is a way of fishing the past from the disposal, wiping it off, painting over the ugly parts and recycling it for more than its worth ~ Baz Luhrmann - Everybody's Free (To Wear Sunscreen)

Offline CharlieBrady

  • *
  • 6,918
  • +3/-0
Re: Date go creazy
« Reply #29 on: December 14, 2008, 11:00:37 PM »
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.