Bug 4056

Summary: anomalous user time from clock(3)/times(3)/setitimer(3) on SMP alpha
Product: [Retired] Red Hat Linux Reporter: Jeff Johnson <jbj>
Component: kernelAssignee: Cristian Gafton <gafton>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0CC: gafton, ken.crandall, michael.waite
Target Milestone: ---   
Target Release: ---   
Hardware: alpha   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jeff Johnson 1999-07-15 16:17:20 UTC
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 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    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 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?