• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 832
  • Last Modified:

Fixing time drift

Our servers info:
Red Hat 9
[foxadm@xxx foxadm]$ uname -a
Linux xxx.xxx.com 2.4.21 #1 SMP Wed Jun 16 15:36:44 EDT 2004 i686 i686 i386 GNU/Linux

One of our servers has been experiancing some serious time drift (about 30 minutes a day). the hardware clock is fine, its the system clock that seems to be drifting.

Ex. /usr/sbin/hwclock --systohc was run less than 24 hours ago:

[foxadm@xxx foxadm]$ date;/usr/sbin/hwclock
Wed Oct 20 12:04:06 EDT 2004
Wed 20 Oct 2004 11:49:49 AM EDT  -0.346284 seconds

I have a cron job running every 10 minutes to sync the system clock, but Im not sure I like this arangement.

I understand ther is a utility (adjtimex) for adjusting the timing in the kernel. Could someone provide some examples of how to use it or does anyone have any other advice on how to fix this problem?

TIA
0
squatex
Asked:
squatex
  • 3
  • 2
  • 2
  • +2
1 Solution
 
ITG-SSNACommented:
Install and use rdate.

crontab -e

0 * * * * /usr/sbin/rdate -s time.mit.edu

(Or wherever your path is, try 'which rdate' to see if it is already installed)

Regards,

~K Black
Irvine, Ca.
0
 
squatexAuthor Commented:
Thats not really what im looking for. I can get the same results with hwclock as the hardware clock is keeping time correctly. I already have a cron job which does this. Im looking for a more elegant solution.
0
 
ITG-SSNACommented:
Well linux likes to sync up system time with CMOS before it changes it's runlevel at reboot.
Therefore I'd suspect this "more elegant solution" you are looking for might come in the form
of a new CMOS battery :)

~K Black
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
squatexAuthor Commented:
The CMOS battery has been changed. Its not the hardware clock thats incorrect. The CMOS keeps perfect time.  It's the system clock. If i were to reboot (i have) right now the system time would be correct....for a few minutes. After 15 minutes the system clock would be several seconds faster than the hardware clock (which is still correct).

Like I said before, I can correct this (by running hwclock --systohc every few minutes from a cron job to sysnc the system clock to hardware - this happens during init at every boot) but I am hoping to find a better solution.

There is a utility called adjtimex that adjusts the tick frequency and latency in the kernel. Im just not sure how to get it to fix my problem. I was hoping someone could provide me with some examples.
0
 
paranoidcookieCommented:
What you need is network time protocol, its really clever syncing to an atomic clock from the internet calculating the cmos clock drift so the results get better over time. It also make minor adjustments at a time so dosnt bugger up services like cryptography

http://www.ntp.org/

0
 
blklineCommented:
What I would do is reset the time again (rdate -s clock.psu.edu;hwclock --systohc), then rm /etc/adjtime.  It may be that your  time was so skewed initially that the drift adjustment is totally out of whack.  

I've had this same problem before and I fixed it using those steps.
0
 
paranoidcookieCommented:
As an added bonus you can put it on all your server and keep them all sychronised. I used to have massive problems using dns tsig until I started using ntp
0
 
MysidiaCommented:
I think you have the right idea with adjtimex
http://www.togaware.com/linux/survivor/Using_adjtimex.shtml

Debian and possibly some other distributions provide an  adjtimexconfig  program
to automatically adjust it to within the accuracy of your hardware clock.

Running  a ntp  aka xntp or some other similar package would help keep
the clock synchronized hopefully to within a second with a time server,
but only if the system is networked.

But it may not solve the problem very well.   It's not ideal to be needing major corrections
to the system time.   If your clock is drifting _that_ much, then I wouldn't say that resyncing
with crontab is ideal.

One possible concern of "patching" a bad system clock timing is it could effect other timed things going on in the system.. i.e. if a program uses the system time during execution as reported by the kernel (registering a negative or errorful total time difference between two points if there was a huge clock drift between synchronization times causing a sudden "jump" in the current system time).

0
 
paranoidcookieCommented:
ntp will use the drift statists to help keep the system clock inline even if you lose networking. Plus if you have it running on multiple ervers at least they will sync to each other and after all that is the most important thing on the network that the servers are in time sync with each other as a lot of updates use time as a frame of reference.
0

Featured Post

Vote for the Most Valuable Expert

It’s time to recognize experts that go above and beyond with helpful solutions and engagement on site. Choose from the top experts in the Hall of Fame or on the right rail of your favorite topic page. Look for the blue “Nominate” button on their profile to vote.

  • 3
  • 2
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now