Red Hat Bugzilla – Bug 4056
anomalous user time from clock(3)/times(3)/setitimer(3) on SMP alpha
Last modified: 2008-08-01 12:22:51 EDT
Here's the output, program attached
Linux version 2.2.5-24smp (firstname.lastname@example.org)
(gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2
#1 SMP Fri Jul 9 16:00:42 EDT 1999
gettimeofday() reports 9.1871 seconds real time elapsed
clock() reports 73435216 cpu time or 73.4352 seconds
times() reports 9403 clock ticks or 75240 user and 1 sys
itimer reports 9.1831 real time, 73.4759 user, and 9.1850
gettimeofday() reports 9.1808 seconds real time elapsed
clock() reports 73395200 cpu time or 73.3952 seconds
times() reports 9397 clock ticks or 75200 user and 0 sys
itimer reports 9.1772 real time, 73.4368 user, and 9.1792
Note: this problem is present in glibc-2.1.2 (from Ken Crandall).
*** Bug 3838 has been marked as a duplicate of this bug. ***
There seems to be a problem with process CPU time display on
Linux Alpha systems. The process CPU
time increments MUCH faster than wall clock time. The CPU
time seems to be about 8 to 10 times faster
than wall clock time. You can see this with either a "w"
display or a "top" display. For example:
[hibbert@spe85 ~]$ w
Unknown HZ value! (2048) Assume 1024.
3:47pm up 38 min, 5 users, load average: 1.85, 1.27,
USER TTY FROM LOGIN@ IDLE JCPU
root tty1 - 3:09pm 0.00s 1.02s
0.78s talk cnbc
root tty2 - 3:39pm 3:29 0.27s
cnbc pts/0 VIM.BOLTZ.CS.CMU 3:29pm 0.00s 7.03s
0.55s talk root@spe85
hibbert pts/1 tnt1-159.mtco.co 3:44pm 1:55 15:12
hibbert pts/2 tnt1-159.mtco.co 3:45pm 0.00s 0.43s
Note that the first hibbert process has been logged in for
only about 2 minutes, yet has used 15 minutes of
CPU time. I know Alpha's are fast, but I didn't think they
could bend time! This bug does not appear to
be a problem for the Proliant Intel based system.
I have been trying to track down this problem. I suspect
there is a system function that convers CPU ticks
to seconds that is assuming the Alpha is using the common PC
interval clock rate of 100/second rather than
the 1K/second rate that most Alpha's actually use. I have
not been able to locate the source code for the
"w" program to see what function calls it uses to convert
This appears to be a 2.2.5smp kernel bug: the user time returned
by the times system call seems to be incorrect.
This should be fixed in a later release of the linux kernel, which I
am putting out now.
There is a kernel-2.2.10-3 now in the tree - can anybody tell me if
the problem is still there so that I can get rth on board?