Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 4056 - anomalous user time from clock(3)/times(3)/setitimer(3) on SMP alpha
Summary: anomalous user time from clock(3)/times(3)/setitimer(3) on SMP alpha
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 6.0
Hardware: alpha
OS: Linux
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
: 3838 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 1999-07-15 16:17 UTC by Jeff Johnson
Modified: 2008-08-01 16:22 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed:

Attachments (Terms of Use)

Description Jeff Johnson 1999-07-15 16:17:20 UTC
Here's the output, program attached

Linux version 2.2.5-24smp (
(gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2
#1 SMP Fri Jul 9 16:00:42 EDT 1999

glibc-2.1.1-7 :

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

glibc-2.1.2-1 :

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

Comment 1 Jeff Johnson 1999-07-15 16:24:59 UTC
Note: this problem is present in glibc-2.1.2 (from Ken Crandall).

Comment 2 Jeff Johnson 1999-07-23 09:28:59 UTC
*** 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
0.14s  -bash
cnbc     pts/0    VIM.BOLTZ.CS.CMU  3:29pm  0.00s  7.03s
0.55s  talk root@spe85
hibbert  pts/1  3:44pm  1:55  15:12
15:11   ./setiathome
hibbert  pts/2  3:45pm  0.00s  0.43s
0.06s  w

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
the time.

Comment 3 Jeff Johnson 1999-07-23 09:32:59 UTC
This appears to be a 2.2.5smp kernel bug: the user time returned
by the times system call seems to be incorrect.

Comment 4 Cristian Gafton 1999-07-28 07:58:59 UTC
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?

Note You need to log in before you can comment on or make changes to this bug.