2

I have a single-core x86 machine where I execute the burnP6(from cpuburn package) for 1 second and then kill the program:

while true; do /usr/bin/burnP6 & sleep 1; pkill burnP6; sleep 1; done

If I check the CPU utilization with top -d 1, the load for burnP6 process is usually less than 50%. If I run the while true; do ps -e -o cmd,pcpu | grep burnP6; done command, the CPU load has following characteristics:

/usr/bin/burnP6              0.0
/usr/bin/burnP6              9.0
/usr/bin/burnP6             10.0
/usr/bin/burnP6             10.0
/usr/bin/burnP6             11.0
/usr/bin/burnP6             11.0
/usr/bin/burnP6             12.0
/usr/bin/burnP6             12.0
/usr/bin/burnP6             13.0
/usr/bin/burnP6             14.0
/usr/bin/burnP6             15.0
/usr/bin/burnP6             15.0
/usr/bin/burnP6             16.0
/usr/bin/burnP6             16.0
/usr/bin/burnP6             17.0
/usr/bin/burnP6             18.0
/usr/bin/burnP6             18.0
/usr/bin/burnP6             19.0
/usr/bin/burnP6             20.0
/usr/bin/burnP6             20.0
/usr/bin/burnP6             21.0
/usr/bin/burnP6             22.0
/usr/bin/burnP6             22.0
/usr/bin/burnP6             23.0
/usr/bin/burnP6             24.0
/usr/bin/burnP6             24.0
/usr/bin/burnP6             25.0
/usr/bin/burnP6             25.0
/usr/bin/burnP6             26.0
/usr/bin/burnP6             27.0
/usr/bin/burnP6             28.0
/usr/bin/burnP6             28.0
/usr/bin/burnP6             28.0
/usr/bin/burnP6             30.0
/usr/bin/burnP6             30.0
/usr/bin/burnP6             31.0
/usr/bin/burnP6             31.0
/usr/bin/burnP6             32.0
/usr/bin/burnP6             32.0
/usr/bin/burnP6             33.0
/usr/bin/burnP6             33.0
/usr/bin/burnP6             35.0
/usr/bin/burnP6             35.0
/usr/bin/burnP6             36.0
/usr/bin/burnP6             36.0
/usr/bin/burnP6             37.0
/usr/bin/burnP6             38.0
/usr/bin/burnP6             38.0
/usr/bin/burnP6             39.0
/usr/bin/burnP6             40.0
/usr/bin/burnP6             40.0
/usr/bin/burnP6             41.0
/usr/bin/burnP6             42.0
/usr/bin/burnP6             42.0
/usr/bin/burnP6             43.0
/usr/bin/burnP6             44.0
/usr/bin/burnP6             44.0
/usr/bin/burnP6             45.0
/usr/bin/burnP6             45.0
/usr/bin/burnP6             46.0
/usr/bin/burnP6             46.0
/usr/bin/burnP6             47.0
/usr/bin/burnP6             48.0
/usr/bin/burnP6             48.0
/usr/bin/burnP6             49.0
/usr/bin/burnP6             50.0
/usr/bin/burnP6             50.0
/usr/bin/burnP6             51.0
/usr/bin/burnP6             52.0
/usr/bin/burnP6             52.0
/usr/bin/burnP6             53.0
/usr/bin/burnP6              0.0

As seen above, the load will quickly go from 0% to 53%, but then the burnP6 process is killed, i.e. it runs for too short time to reach 99% - 100% utilization. Are those results caused by measuring method and actually the burnP6 process utilizes CPU 100% from the very first microsecond? :) Or does it indeed take process 1 to 2 seconds to get all the CPU time?

Martin
  • 7,516
  • 1
    Related: Top and ps not showing the same cpu result – don_crissti Nov 18 '14 at 09:26
  • @don_crissti In my case both top and ps show the same results because I constantly start new burnP6 processes. burnP6 process runs for too short time to show 100% CPU usage in top or ps. However, I think I got my answer from this very same thread you pointed in your comment- at any given moment a process either uses the CPU or not. Thus you have either 0% or 100% load in that exact moment. This means that actually the CPU usage of burnP6 process is 100% from the very first microsecond. Is there an utility which allows to measure CPU usage for micro- or millisecond intervals? – Martin Nov 19 '14 at 12:03

1 Answers1

4

The command that you're using to display the CPU load is running in a tight loop, so it's competing with CPUburn. If you want to observe the CPU load that CPUburn would have with no competition, add something like sleep 1 in the loop.

In your test, initially the observer loop gets pretty much all the CPU, then progressively the burnP6 gain more and more CPU share. This is a consequence of Linux's scheduling policy. The Linux kernel has a complex scheduler — actually, it has many scheduling algorithms, and you can configure which one(s) to use at run time. Read the sched(7) man page for an introduction, and the kernel documentation and the referenced book if you want to dig into more details.

A more knowledgeable person than me could tell by this output which scheduler is active on your system. I can't. I can see that it privileges I/O programs (the ps | grep loop, which pretty much does nothing but load executables, create processes and pass data around) over high CPU consumers. This makes sense in many situations: the CPU-intensive program probably doesn't mind spending 1.1s instead of 1s on a calculation, whereas the I/O-intensive program is often a user interface thread or a network service for which a fast response time (low latency) is appreciated. There is apparently some kind of fairness measure which then pushes the balance away from the process group that's been hogging all the CPU.

It would be instructive to play with the settings in /proc/sys/kernel/sched* and see how the behavior varies.

Gilles 'SO- stop being evil'
  • 829,060
  • I see what you mean. Thanks! In addition, I did some additional testing and looks like top -d 1 works in a way that it really measures process CPU usage within the one second, e.g. if burnP6 is started at the half of this interval(at 0.5s), then the CPU usage of burnP6 is shown as 50%. This can be tested if while true; do /usr/bin/burnP6 & sleep 1; pkill burnP6; done is running and one starts the top -d 1 at different times. This obviously means that if process really runs only for 30ms, then the maximum load one can see for this process in top output is 30%. Do you agree? – Martin Nov 21 '14 at 11:07
  • @Martin If you want reliable data about CPU usage, you need to sample for a time that's less than the lifetime of the process. When you start a new instance of burnP6 every second, with top refreshing every second, you may see a figure that's lower than the actual usage. On the second refresh of top showing the same process instance, you'll get a reliable figure. – Gilles 'SO- stop being evil' Nov 21 '14 at 11:11
  • Exactly. Is there an utility which allows to measure CPU usage for micro- or millisecond intervals? – Martin Nov 21 '14 at 11:38
  • @Martin Microsecond intervals wouldn't make sense, that's smaller than a time slice. Intervals of about 0.1s should give decent results, try top -d 0.1. – Gilles 'SO- stop being evil' Nov 21 '14 at 12:30