16

While running mencoder with threads=4 (on a quad-core cpu). I've noticed that htop does not show its true CPU usage, but top does.

It seems that htop is only reporting on one core. Is this a bug/limitation of htop? What is going on here?

There are no other entries for mencoder show up in ps or htop or top. I assume that 100% means that 1 core is maxed out, but even this seems odd to me; what about the other cores?

Update: added "System Monitor" output

                  PID   %CPU   COMMAND                    
           "top"  1869   220   mencoder                 
          "htop"  1869    95   mencoder -noodml /media/...  
"System Monitor"  1869   220   mencoder
4
  • What flags are you using for htop?
    – sep332
    Dec 1, 2010 at 3:25
  • sep332... I just run "htop" ... so it's a case of whatever the defaults are.
    – Peter.O
    Dec 1, 2010 at 3:27
  • Bingo! sep332.. make an answer out of that and I'lll mark it solved.. You got me looking at my defaults.... "H" is a toggle key to "Hide user threads" ... When all else fails "Read the info help", but sometimes a handy hint in the right directon helps more.. Thanks.
    – Peter.O
    Dec 1, 2010 at 3:36
  • @Peter.O: Accidentally downvoted (mouse touchpad!). I'll cancel it if you edit your post.
    – SabreWolfy
    Jun 23, 2012 at 11:06

1 Answer 1

32

As you've said yourself, you can hit H to show user threads.

Just for future reference (and for fun), let's calculate CPU utilisation!

A bit of background:

In a modern operating system, there's a Scheduler. It aims to ensure that all of the Processes and their threads get a fair share of computing time. I won't go into scheduling too much (it's really complicated). But in the end there is something called a run queue. This is where all the instructions of all of the processes line up to wait for their turn to be executed.

Any process puts it's "tasks" on the run queue, and once the processor's ready, it pops them off and executes them. When a program goes to sleep, for example, it removes itself from the run queue and returns to the "end of the line" once it's ready to run again.

Sorting on this queue has to do with the processes' Priority (also called "nice value" - i.e. a process is nice about system resources).

The length of the queue determines the Load of the system. A load of 2.5 for example means that there are 2.5 instructions for every instruction the CPU can deal with in real time.

On Linux, by the way, this load is calculated in 10ms intervals (by default).

Now onto the Percentage values of CPU utilisation:

Imagine you have two clocks, one is called t and it represents real time. It measures a second for every second. The other clock we call c . It only runs if there is processing to do. That means, only when a process calculates something does the clock run. This is also called CPU time. Each and every process on the system 'has got' one of those.

The processor utilisation can now be calculated for a single process:

U = c/t = 0.5s / 1s = 0.5

or for all processes:

alt text

On a multi core machine, this may result in a value of 3.9 of course, because the CPU can calculate four seconds worth of computation every second, if utilised perfectly.

Wikipedia provides this example:

A software application running in 6-CPU UNIX machine creates three UNIX processes for fulfilling the user requirement. Each of these three processes create two threads. Work of software application is evenly distributed on 6 independent threads of execution created for the application. If no wait for resources is involved, Total CPU time is expected to be six times Elapsed real time.

Here's a small python snippet that does this

>>> import time
>>> t = time.time()
>>> c = time.clock()
>>> # the next line will take a while to compute
>>> tuple(tuple(i**0.2 for i in range(600)) for i in range(6000))
>>> print (time.clock() / (time.time() - t)) * 100, "%"
66.9384021612 %

In a perfect world, you could infer from this that system load is 100 - 66.93 = 33,1%. (But in reality that'd be wrong because of complex things like I/O wait, scheduling inefficiencies and so on)

In contrast to load, these calculations will always result in a value between 0 and the number of processors, i.e. between 0 and 1 or 0 to 100%. There is now no way to differentiate between a machine that is running three tasks, utilising 100% cpu, and a machine running a million tasks, getting barely any work done on any single one of them, also at 100%. If you're, for instance, trying to balance a bunch of processes on many computers, cpu utilisation is next to useless. Load is what you want there.

Now in reality, there is more than one of those processing time clocks. There's one for waiting on I/O for example. So you could also calculate I/O resource utilisation.

This may not have been helpful regarding the original question, but I hope it's interesting. :)

2
  • I should really have included uncertainty values, because using this simple method, the calculation will probably be off by ±1%, but I didn't want to bore everybody too much. Dec 1, 2010 at 9:40
  • Thanks for the lesson. I knew most of that but a few things were more specific than what I learned. Dec 1, 2010 at 14:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .