System clock slow; Hardware clock fine

[voxelbox]

I recently installed FC2 on an AMD K6-2 machine. Everything appears to work fine, except that the system clock is very slow.

I checked the hardware clock and that seems to be correct. It's just the system clock that is slow.

I compared the system clock and hardware clock by issuing the following command repeatedly:

date +"%a %d %b %Y %I:%M:%S %p %Z";/sbin/hwclock

The output is:
======================================
[root@leon log]# date +"%a %d %b %Y %I:%M:%S %p %Z";/sbin/hwclock
Tue 27 Jul 2004 03:43:31 PM EDT
Tue 27 Jul 2004 03:53:23 PM EDT -0.175582 seconds
[root@leon log]# date +"%a %d %b %Y %I:%M:%S %p %Z";/sbin/hwclock
Tue 27 Jul 2004 03:43:31 PM EDT
Tue 27 Jul 2004 03:53:24 PM EDT -0.170541 seconds
[root@leon log]# date +"%a %d %b %Y %I:%M:%S %p %Z";/sbin/hwclock
Tue 27 Jul 2004 03:43:31 PM EDT
Tue 27 Jul 2004 03:53:25 PM EDT -0.169484 seconds
[root@leon log]# date +"%a %d %b %Y %I:%M:%S %p %Z";/sbin/hwclock
Tue 27 Jul 2004 03:43:32 PM EDT
Tue 27 Jul 2004 03:53:26 PM EDT -0.166913 seconds
[root@leon log]# date +"%a %d %b %Y %I:%M:%S %p %Z";/sbin/hwclock
Tue 27 Jul 2004 03:43:32 PM EDT
Tue 27 Jul 2004 03:53:27 PM EDT -0.146059 seconds
[root@leon log]# date +"%a %d %b %Y %I:%M:%S %p %Z";/sbin/hwclock
Tue 27 Jul 2004 03:43:32 PM EDT
Tue 27 Jul 2004 03:53:28 PM EDT -0.145522 seconds
[root@leon log]# date +"%a %d %b %Y %I:%M:%S %p %Z";/sbin/hwclock
Tue 27 Jul 2004 03:43:33 PM EDT
Tue 27 Jul 2004 03:53:29 PM EDT -0.136138 seconds
[root@leon log]# date +"%a %d %b %Y %I:%M:%S %p %Z";/sbin/hwclock
Tue 27 Jul 2004 03:43:33 PM EDT
Tue 27 Jul 2004 03:53:30 PM EDT -0.125849 seconds
[root@leon log]#
======================================

You can see the the seconds of the system clock only change after 3 or so seconds of the hardware clock. Because the seconds of the system clock tick so slowly, the time falls behind.

I set up ntpd to sync the time, but this doesn't help because once the daemon sets the time, the system clock ticks too slowly and the time falls behind.

Any ideas?

[Jman]

How much load is on your machine? Because if the software clock can't be updated under heavy load, it falls behind.

this might be another bug. I had a similar problem when I upgraded from fc1. Something about loosing ticks, since then I had reinstalled (clean install) and everything worked great, sorda. but if yours is not the result of an uprade, perhaps its something else.

[voxelbox]

Originally Posted by Jman

How much load is on your machine? Because if the software clock can't be updated under heavy load, it falls behind.

I don't think the load is that bad. I'm only running the following:

==============================================
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 14:54 ? 00:00:03 init [5]
root 2 1 0 14:54 ? 00:00:00 [ksoftirqd/0]
root 3 1 0 14:54 ? 00:00:00 [events/0]
root 4 3 0 14:54 ? 00:00:00 [khelper]
root 5 3 0 14:54 ? 00:00:00 [kacpid]
root 16 3 0 14:54 ? 00:00:00 [kblockd/0]
root 17 1 0 14:54 ? 00:00:00 [khubd]
root 28 3 0 14:54 ? 00:00:00 [pdflush]
root 29 3 0 14:54 ? 00:00:00 [pdflush]
root 31 3 0 14:54 ? 00:00:00 [aio/0]
root 30 1 0 14:54 ? 00:00:00 [kswapd0]
root 136 1 0 14:54 ? 00:00:00 [kseriod]
root 175 1 0 14:54 ? 00:00:00 [kjournald]
root 916 1 0 14:54 ? 00:00:00 [kjournald]
root 1310 1 0 14:55 ? 00:00:00 /sbin/dhclient -1 -q -lf /var/lib/dhcp/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid
root 1350 1 0 14:55 ? 00:00:00 syslogd -m 0
root 1354 1 0 14:55 ? 00:00:00 klogd -x
rpc 1375 1 0 14:55 ? 00:00:00 portmap
root 1402 1 0 14:55 ? 00:00:01 rpc.idmapd
root 1492 1 0 14:55 ? 00:00:00 /usr/sbin/smartd
root 1502 1 0 14:55 ? 00:00:00 /usr/sbin/acpid
root 1514 1 0 14:55 ? 00:00:00 /usr/sbin/sshd
root 1531 1 0 14:55 ? 00:00:00 xinetd -stayalive -pidfile /var/run/xinetd.pid
root 1562 1 0 14:55 ? 00:00:01 gpm -m /dev/input/mice -t imps2
root 1573 1 0 14:55 ? 00:00:00 crond
xfs 1595 1 0 14:55 ? 00:00:00 xfs -droppriv -daemon
daemon 1614 1 0 14:55 ? 00:00:00 /usr/sbin/atd
dbus 1633 1 0 14:55 ? 00:00:00 dbus-daemon-1 --system
root 1649 1 0 14:55 ? 00:00:00 mdadm --monitor --scan
root 1679 1 0 14:55 tty1 00:00:00 /sbin/mingetty tty1
root 1680 1 0 14:55 tty2 00:00:00 /sbin/mingetty tty2
root 1691 1 0 14:55 tty3 00:00:00 /sbin/mingetty tty3
root 1697 1 0 14:55 tty4 00:00:00 /sbin/mingetty tty4
root 1703 1 0 14:55 tty5 00:00:00 /sbin/mingetty tty5
root 1798 1 0 14:55 tty6 00:00:00 /sbin/mingetty tty6
root 1805 1 0 14:55 ? 00:00:00 /usr/bin/gdm-binary -nodaemon
root 1898 1805 0 14:55 ? 00:00:00 /usr/bin/gdm-binary -nodaemon
root 1909 1898 0 14:55 ? 00:00:49 /usr/X11R6/bin/X :0 -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7
gdm 1938 1898 0 14:55 ? 00:00:52 /usr/bin/gdmgreeter
ntp 3363 1 0 15:35 ? 00:00:05 ntpd -U ntp -p /var/run/ntpd.pid
root 4214 1514 4 17:32 ? 00:00:00 sshd: chris [priv]
chris 4216 4214 0 17:32 ? 00:00:00 sshd: chris@pts/17
chris 4217 4216 0 17:32 pts/17 00:00:00 -bash
root 4243 4217 0 17:32 pts/17 00:00:00 su
root 4244 4243 0 17:32 pts/17 00:00:00 bash
root 4262 4244 0 17:32 pts/17 00:00:00 ps -ef
==============================================

Also, I had FC2 installed on another machine with a slower processor and less RAM and had no issue with the clock.

Thanks for the link, though.

[voxelbox]

Originally Posted by superbnerd

this might be another bug. I had a similar problem when I upgraded from fc1. Something about loosing ticks, since then I had reinstalled (clean install) and everything worked great, sorda. but if yours is not the result of an uprade, perhaps its something else.

I think it has something to do with the processor. I was running FC2 on a PII-300mHz and had no problem. My current system is an AMD K6-2 500mHz. My guess is that this chip handles time in some way that Fedora doesn't like.

your absolutely right. it is a processors problem, but it is not exclusively the proccessors fault. It might help to compile your own kernel. that way you will include your cpu specific extentions. this should also speed things up.

[voxelbox]

Originally Posted by superbnerd

your absolutely right. it is a processors problem, but it is not exclusively the proccessors fault. It might help to compile your own kernel. that way you will include your cpu specific extentions. this should also speed things up.

Wow. Ok. What sort of parameters can I change and where would I change them? I'm not really familiar with the kernel settings that affect processors, or kernel settings at all. If you have time, could you point me in the right direction?

Thanks.

Chris G.

[duncan]

I would run:
adjtimex -a

next time you system is busy.
duncan

[zphelj]

I've rebuild the 2.6.8.-1.521 kernel sources and still have this problem. I found a bug report which appears to be the same issue,

https://bugzilla.redhat.com/bugzilla....cgi?id=127411