Bug 89185 - Top command reports incorrect times.
Top command reports incorrect times.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: procps (Show other bugs)
7.3
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Daniel Walsh
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-19 13:01 EDT by Jean-David Beyer
Modified: 2007-04-18 12:53 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-02-11 08:27:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jean-David Beyer 2003-04-19 13:01:45 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
Times reported are manifestly incorrect when times are large and reported in
hours. Here are a few lines from top command that illustrate the problem. My
machine has 2 CPUs.

 12:40pm  up 31 days, 15:36,  3 users,  load average: 4.15, 4.10, 4.06

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM  CTIME COMMAND
    1 root      15   0   512  460   440 S     0.0  0.0 10958h init [5]   

Since I have two CPUs, CTIME for init should not exceed 1524 hours at this point.

When I first boot the system, and times are reported in minutes and seconds, the
times are very likely correct, but when it needs hours, they are wrong like this.

Version-Release number of selected component (if applicable):
procps-2.0.7-12  kernel-smp-2.4.18-27.7.x

How reproducible:
Always

Steps to Reproduce:
1. Boot system and run top.
2. Observe correct timings.
3. Ensure system has heavy CPU load (e.g., seti@home) or wait longer.
4. Wait a few weeks. It is not necessary to run top continuously.
5. Observe times go wrong when top reports them in hours.
    

Actual Results:   12:40pm  up 31 days, 15:36,  3 users,  load average: 4.15,
4.10, 4.06

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM  CTIME COMMAND
    1 root      15   0   512  460   440 S     0.0  0.0 10958h init [5]

Expected Results:  Something like this: 

12:40pm  up 31 days, 15:36,  3 users,  load average: 4.15, 4.10, 4.06

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM  CTIME COMMAND
    1 root      15   0   512  460   440 S     0.0  0.0 91440m init [5]

or like this:

 12:40pm  up 31 days, 15:36,  3 users,  load average: 4.15, 4.10, 4.06

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM  CTIME COMMAND
    1 root      15   0   512  460   440 S     0.0  0.0  1524h init [5]

Additional info:

I have another machine with 7.3 i586 platform with just one CPU. Currently its
top command reads "31290m" for the time of init (has not been up as long, and is
running only one instance of seti@home). It is up to date using up2date just as
this system is. Since that machine is frequently rebooted, I have never observed
this problem on it, but my guess is that it would be the same.
Comment 1 Alexander Larsson 2003-04-24 11:45:36 EDT
Strange. The formating code looks ok on a quick glance.
Comment 2 Alexander Larsson 2003-04-25 03:44:45 EDT
Can you try after toggling 'S' too.
Also compare it to the TIME field in ps at the same time.

The source of this data is the ctime and utime fields in /proc/1/stat, so please
paste that in the bug too while this happens.
Comment 3 Jean-David Beyer 2003-04-25 07:33:59 EDT
I had to reboot a few days ago, so the ctime for init is now at 7421 minutes
and, of course, I do not see the problem. 

I have run, as root, ps --cumulative -flx and observed that the time is the same
as shown by top. I have toggled S in top, and it works as expected. I did a cat
/proc/1/stat and get a lot of stuff, but I do not know how to interpret it. I
would have expected to see a number like 445260 (7421*60) in there somewhere,
but I do not.  Perhaps because the regular (not cumulative time) for init is 10
seconds. It looks like this:

cat /proc/1/stat
1 (init) S 0 0 0 0 -1 256 88 68457443 122 1925108 227 796 43772740 757274 15 0 0
0 29 1404928 109 4294967295 134512640 134536766 3221223744 3221222496 1108220398
0 0 1475401980 671819267 3222431532 0 0 0 1


It will be a few weeks before the cumulative time for init gets back up to where
the problem is observable. I am not ignoring you.
Comment 4 Alexander Larsson 2003-04-28 06:52:43 EDT
If you skip 10 numbers after the 'S' you get to "utime stime cutime cstime".
So you have:
utime: 227
stime: 796
cutime: 43772740
cstime: 757274

For cummulative time you get cutime + cstime =  44530014 ticks, which (since
userspace Hz=100) is 445300 secs, or 7421 minutes.
Comment 5 Alexander Larsson 2003-04-28 06:55:23 EDT
Btw. This could easily have been fixed in later procps, so you could try
rebuilding the latest procps from e.g. RH9 and run that.

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