Discrepancy in TIME+ Column: Why top Command Shows Inaccurate CPU Time for Long-Running Processes


10 views

During routine system administration, I encountered an interesting case where the top command's TIME+ column displayed inconsistent values. While running a recursive chown operation:

chown -R me:me allMyMusic

The process ran for approximately 5 minutes, yet top reported:

TIME+: 0:12.10

The TIME+ field in top represents the total CPU time used by the process since start, measured in hundredths of a second. The format is:

MM:SS.ss

Key factors affecting its behavior:

  • Only counts actual CPU time, not wall-clock time
  • Depends on process scheduling and CPU availability
  • Increments only when process actively uses CPU

To test this behavior, I created a simple Python script that alternates between computation and sleep:

import time
import math

start = time.time()
for i in range(100):
    # CPU-intensive operation
    [math.exp(x) for x in range(100000)]
    # Sleep period
    time.sleep(1)
print(f"Wall time: {time.time()-start:.2f}s")

Running this script while monitoring with top shows:

  • Wall time: ~100 seconds
  • TIME+: ~10-15 seconds (varies by system)

For more accurate time tracking, consider:

# Using time command
/usr/bin/time -v chown -R me:me allMyMusic

# Using ps command
ps -eo pid,etime,time,cmd | grep chown

The etime field in ps shows elapsed wall-clock time, while time shows CPU time similar to TIME+.

Several system factors can affect TIME+ accuracy:

  • CPU throttling/power management
  • Process priority (nice values)
  • System load and process scheduling
  • I/O wait times during filesystem operations

For filesystem-heavy operations like chown, the process spends significant time waiting for I/O completion, during which it doesn't accumulate CPU time.


While monitoring a recursive chown operation:

chown -R user:group /large_directory

The process had been running for approximately 5 minutes, yet top reported:

TIME+ 
0:12.10

The counter increments much slower than real-time, suggesting either:

  1. Measurement methodology issues
  2. Kernel reporting limitations
  3. Process state complications

Linux tracks two types of process time:

1. User time (time spent in user space)
2. System time (time spent in kernel space)

The TIME+ field sums these values, but with important caveats:

  • Only counts when process is actively scheduled on CPU
  • IO-bound processes show lower values
  • Multi-threaded processes may report inconsistently

Cross-check with alternative tools:

ps -eo pid,etime,time,cmd | grep chown
# ETIME shows real elapsed time
# TIME shows CPU time (matches TIME+)

Or for continuous monitoring:

watch -n 1 'ps -p $PID -o etime,time,cmd'

Common scenarios causing discrepancies:

1. Filesystem operations (chown/chmod on NFS)
2. Process waiting for disk I/O
3. CPU throttling situations
4. Process in uninterruptible sleep (D state)

Example showing D-state processes:

top -b -n 1 | awk '$8 == "D" {print}'

For accurate elapsed time measurement:

# Method 1: Using time command
/usr/bin/time -v chown -R user:group /path

# Method 2: Using strace
strace -T -ttt -o chown_trace.log chown -R user:group /path

For batch processing analysis:

awk '/^real/ {print $2}' time_output.log