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
LVL 4
squatexAsked:
Who is Participating?
 
MysidiaConnect With a Mentor Commented:
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
 
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
Cloud Class® Course: Microsoft Office 2010

This course will introduce you to the interfaces and features of Microsoft Office 2010 Word, Excel, PowerPoint, Outlook, and Access. You will learn about the features that are shared between all products in the Office suite, as well as the new features that are product specific.

 
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
 
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
 
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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.