search

nikademus79 / psutil

Automatically exported from code.google.com/p/psutil
Other
0 stars 0 forks source link

psutil.cpu_percent does not work as advertised #168

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Call psutil.cpu_percent(interval=0) multiple times.

What is the expected output? What do you see instead?
Expected: each call should give cpu usage since previous call.
Actual: gives cpu usage since module import.

Please provide any additional information below.

I think this fixes the problem:

Index: psutil/__init__.py
===================================================================
--- psutil/__init__.py  (revision 980)
+++ psutil/__init__.py  (working copy)
@@ -601,7 +601,7 @@
     t2_all = sum(t2)
     t2_busy = t2_all - t2.idle

-    _last_cpu_times = t1
+    _last_cpu_times = t2
     # this usually indicates a float precision issue
     if t2_busy <= t1_busy:
         return 0.0

Original issue reported on code.google.com by philip.r...@gmail.com on 3 Jun 2011 at 2:23

GoogleCodeExporter commented 8 years ago 
> Expected: each call should give cpu usage since previous call.
> Actual: gives cpu usage since module import.

I think you're misinterpreting the code.
This is true only *the first time* the function is called.
Since then times are compared against previous function call.

Original comment by g.rodola on 3 Jun 2011 at 7:34

GoogleCodeExporter commented 8 years ago 
The current code looks like this:

   if blocking:
        t1 = cpu_times()
        time.sleep(interval)
    else:
        t1 = _last_cpu_times

    t1_all = sum(t1)
    t1_busy = t1_all - t1.idle

    t2 = cpu_times()
    t2_all = sum(t2)
    t2_busy = t2_all - t2.idle

    _last_cpu_times = t1

So if you are using the non-blocking code, it looks like we set t1 = 
_last_cpu_times and then later we are setting _last_cpu_times = t1 without 
modifying it, so it's effectively a no-op. I guess this got introduced when 
adding the blocking code path.

Original comment by jlo...@gmail.com on 3 Jun 2011 at 4:28

GoogleCodeExporter commented 8 years ago 
You guys are right, sorry.
This is now fixed in r981.

Original comment by g.rodola on 3 Jun 2011 at 5:16

GoogleCodeExporter commented 8 years ago

Original comment by g.rodola on 27 Jun 2011 at 5:52

GoogleCodeExporter commented 8 years ago

Original comment by g.rodola on 8 Jul 2011 at 7:07

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Updated csets after the SVN -> Mercurial migration:
r981 == revision a415d2627242

Original comment by g.rodola on 2 Mar 2013 at 12:00