I have a problem with clock drift on an opteron machine running suse 9.2. I think I've narrowed the problem down to the kernel clock. I stopped NTP so that isn't confusing the issue. I manually set the system clock and the hardware clock to match another NTP-synchronized clock that is working properly and left it for an hour. The hardware clock is still showing the correct time, but the system clock has gained 52 minutes in an hour.
I have had a similar problem and had to resort to setting a cron job restarting xntp every 30 minutes. This appears to be a Suse problem (I have a similar hardware setup as you, 4 dual Opterons running Suse 9.1). The Mandrake servers I have make use of the drift files frequently. Oddly, I have noticed that on the Suse boxes the ntp daemon dies for no apparent reason; # rcxntpd status Checking for network time protocol daemon (NTPD): dead ~James
James D. Parra wrote: [snip]
I have had a similar problem and had to resort to setting a cron job restarting xntp every 30 minutes. This appears to be a Suse problem (I have a similar hardware setup as you, 4 dual Opterons running Suse 9.1). The Mandrake servers I have make use of the drift files frequently. Oddly, I have noticed that on the Suse boxes the ntp daemon dies for no apparent reason; [snip]
I can't recall whether it was on 9.0 or 9.1, but at one time ntp didn't work well on SuSE because the rpm installed an incorrect symlink that prevented the drift file (or something important) from being used. Perhaps worth googling? :) Fish
Mark Crean wrote:
[snip]
I can't recall whether it was on 9.0 or 9.1, but at one time ntp didn't work well on SuSE because the rpm installed an incorrect symlink that prevented the drift file (or something important) from being used. Perhaps worth googling?
I had that same problem, and was about to ask (I'm new to the list). I googled and found the reference you described, and xntp now works perfectly! Thanks! Now if some of my other problems get solved like this... :-) John Perry
On Tuesday 24 May 2005 12:26 pm, James D. Parra wrote:
I have had a similar problem and had to resort to setting a cron job restarting xntp every 30 minutes. Rather than restarting xntp, would it be better simply to run ntpdate since xntp is a daemon.
--
Jerry Feldman
* Jerry Feldman
I have had a similar problem and had to resort to setting a cron job restarting xntp every 30 minutes. Rather than restarting xntp, would it be better simply to run ntpdate since xntp is a daemon.
No, because ntpdate hard sets the clock, whereas xntpd does it gradually. i.e. if your clock is 5 minutes off, ntpdate will kick it back 5 miniutes. Running ntpdate will ensure the clock is always at the right time (an dif there is alarge discrepancy, xntpd will slow down (or speed up) the clock to get it at the right time. Settign the clock backward (or forward) whiel applications are running can cause unpredicatble results (the easiest to imagine is your screensaver immediately kicking in, but MOtif 1.2.X applications don;t like it if they get an answer before they have send the question. [been there, done that]
Currently listening to: Smashing Pumpkins - In the Arms of Sleep Gerhard, (faliquid@xs4all.nl) == The Acoustic Motorbiker == -- __O You have had all that money can give you, but that wasn't enough =`\<, You became a thrill-seeker. Kill for the thrill. (=)/(=) The thrill-seeker comes from all walks of life. He comes from the home, a home where the parents are to busy to treat their children with respect."
The Tuesday 2005-05-24 at 20:07 +0200, Gerhard den Hollander wrote:
Rather than restarting xntp, would it be better simply to run ntpdate since xntp is a daemon.
No, because ntpdate hard sets the clock, whereas xntpd does it gradually.
Not exactly. It will go gradually if the error is less than .5 seconds.
From the doc (/usr/share/doc/packages/xntp-doc/html/ntpdate.html):
Time adjustments are made by ntpdate in one of two ways. If ntpdate determines the clock is in error more than 0.5 second it will simply step the time by calling the system settimeofday() routine. If the error is less than 0.5 seconds, it will slew the time by calling the system adjtime() routine. The latter technique is less disruptive and more accurate when the error is small, and works quite well when ntpdate is run by cron every hour or two. -- Cheers, Carlos Robinson
On Tue, 2005-05-24 at 18:26, James D. Parra wrote:
I have a problem with clock drift on an opteron machine running suse 9.2. I think I've narrowed the problem down to the kernel clock. I stopped NTP so that isn't confusing the issue. I manually set the system clock and the hardware clock to match another NTP-synchronized clock that is working properly and left it for an hour. The hardware clock is still showing the correct time, but the system clock has gained 52 minutes in an hour.
I have had a similar problem and had to resort to setting a cron job restarting xntp every 30 minutes. This appears to be a Suse problem (I have a similar hardware setup as you, 4 dual Opterons running Suse 9.1). The Mandrake servers I have make use of the drift files frequently. Oddly, I have noticed that on the Suse boxes the ntp daemon dies for no apparent reason; # rcxntpd status Checking for network time protocol daemon (NTPD): dead
~James
Hi James, Is every 30 minutes not overdone? I have ntpdate just once every 24 hours (cron) and even that is too often, considering the drift: /var/log/messages.4:Apr 30 01:00:04 fw2 ntpdate[24607]: step time server 193.79.237.14 offset -0.005447 sec If you need to update it that often, one might have a hw-problem... Hans
participants (7)
-
Carlos E. R. -
Gerhard den Hollander -
Hans Witvliet -
James D. Parra -
Jerry Feldman -
John Perry -
Mark Crean