This unique problem I have never encounter before. After we adjust the time and install Network TIme protocol Service (NTP) the clock is still drifting for more than 8 hours in a day.
I had Google for an answer, its may happened be because of the internal clock in the Linux operating systerm. In detail time drifting occurs because of changes made by the operating system.
In-depth, hwclock depend on the file /etc/adjtime to check for drifting information to make the adjustment and /etc/adjtime will make the correction to system to make sure the clock back in order.
My problem occur may due to drifting information below ... Look at the number 550.026225
*** Before delete ***
/etc/adjtime
# file /etc/adjtime
/etc/adjtime: ASCII text
# cat /etc/adjtime
550.026225 1280462978 0.000000
1280462978
LOCAL
I delete /etc/adjtime, adjust the time and hwclock -w to sysnc with hardware clock and a new /etc/adjtime will be made ....
I'm not sure this will solve the problem because it takes 24 hours to see whether drifting with large gap different occurs or not.
*** After delete and recreate ***
/etc/adjtime
# cat /etc/adjtime
0.000000 1280464987 0.000000
1280464987
LOCAL
Format /etc/adjtime
The format of the adjtime file is, in ASCII:
Line 1: 3 numbers, separated by blanks: 1) systematic drift rate in seconds per day, floating point decimal; 2) Resulting number of seconds since 1969 UTC of most recent adjustment or calibration, decimal integer; 3) zero (for compatibility with clock(8)) as a decimal integer.
Line 2: 1 number: Resulting number of seconds since 1969 UTC of most recent calibration. Zero if there has been no calibration yet or it is known that any previous calibration is moot (for example, because the Hardware Clock has been found, since that calibration, not to contain a valid
time). This is a decimal integer.
Line 3: "UTC" or "LOCAL". Tells whether the Hardware Clock is set to Coordinated Universal Time or local time. You can always override this value with options on the hwclock command line.