Bug 4056 - anomalous user time from clock(3)/times(3)/setitimer(3) on SMP alpha
anomalous user time from clock(3)/times(3)/setitimer(3) on SMP alpha
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
alpha Linux
medium Severity medium
: ---
: ---
Assigned To: Cristian Gafton
: 3838 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 1999-07-15 12:17 EDT by Jeff Johnson
Modified: 2008-08-01 12:22 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jeff Johnson 1999-07-15 12:17:20 EDT
Here's the output, program attached

Linux version 2.2.5-24smp (root@jetson.devel.redhat.com)
(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 12:24:59 EDT
Note: this problem is present in glibc-2.1.2 (from Ken Crandall).
Comment 2 Jeff Johnson 1999-07-23 05:28:59 EDT
*** 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    tnt1-159.mtco.co  3:44pm  1:55  15:12
15:11   ./setiathome
hibbert  pts/2    tnt1-159.mtco.co  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 05:32:59 EDT
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 03:58:59 EDT
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.