After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 530268 - wrong percentage with frequency scaling
wrong percentage with frequency scaling
Status: RESOLVED OBSOLETE
Product: system-monitor
Classification: Core
Component: process list
2.22.x
Other All
: Normal minor
: ---
Assigned To: System-monitor maintainers
System-monitor maintainers
: 432892 575057 759330 (view as bug list)
Depends on: 668420
Blocks:
 
 
Reported: 2008-04-27 23:48 UTC by Greg Grossmeier
Modified: 2018-05-22 12:05 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Greg Grossmeier 2008-04-27 23:48:54 UTC
Originally opened on Launchpad: https://launchpad.net/bugs/214695
-----
In system monitor under the tab Processes I can see no process is using more than 10% CPU.
When I select Resources I see CPU1 at 12% and CPU2 at about 40-50%.

If I set the frequency scaling applet to not limit CPU usage and run at 3,20 GHz instead of 400 MHz the percentage in both tabs are compatible.

So, Resources calculates percentage based on what speed my CPU is capped to but Processes always use the value my processor is capable of.

Other information:
~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 8.04
Release: 8.04
Codename: hardy

~$ apt-cache show gnome-system-monitor | grep Version
Version: 2.22.0-1ubuntu3
Comment 1 Benoît Dejean 2008-04-28 12:47:23 UTC
I'll have a look at this one, but it looks difficult:
- the graph uses the global counter in /proc/stat
- each process % is the processor usage delta / global counter

so the graph is :
- used  = NOW[i][CPU_USED]  - LAST[i][CPU_USED];
where the process is :
- info->pcpu = (proctime.rtime - info->cpu_time) * 100 / procdata->cpu_total_time;

Does top have the same behaviour ?
Comment 2 Aaron Bockover 2008-09-03 17:25:56 UTC
Looking at load-graph.cpp, right off the bat one thing I see that would help is
to avoid redrawing the entire graph on each timeout.

In load_graph_draw, gtk_widget_queue_draw is called which in turn will trigger
an expose event on the widget with a single damage rectangle consisting of the
entire widget allocation.

If damage can be computed ahead of time based on the graph points, it could be
beneficial to call gtk_widget_queue_draw_area instead. The expose handler
should then be updated to iterate over the damage rectangles, clip the cairo
context to those regions, and render only what is damaged. 

For instance, if there's been no CPU spike above 10%, then there's no reason to
render the 100%-10% region of the graph on each iteration. Smartly subdividing
the plot into damage regions can help a /lot/.
Comment 3 Aaron Bockover 2008-09-03 17:26:55 UTC
Ugh, stupid bugzilla moving to the next bug. Ignore my comment, it was for the CPU usage bug. Sorry.
Comment 4 Robert Roth 2011-11-15 15:51:30 UTC
*** Bug 432892 has been marked as a duplicate of this bug. ***
Comment 5 Robert Roth 2011-11-15 15:53:01 UTC
*** Bug 575057 has been marked as a duplicate of this bug. ***
Comment 6 Robert Roth 2012-01-22 10:03:12 UTC
Reported a bug on libgtop to be able to pass the cpu frequency scaling info for each core, see bug 668420. This bug is blocked on that one, as until we don't have support for getting the frequency scaling info, there's not much to do here.
Comment 7 André Klapper 2012-02-26 10:46:03 UTC
[Adding missing "QA Contact" entry so system monitor bug report changes can still be watched via the "Users to watch" list on https://bugzilla.gnome.org/userprefs.cgi?tab=email when the assignee is changed to an individual.]
Comment 8 Robert Roth 2015-12-11 20:34:38 UTC
*** Bug 759330 has been marked as a duplicate of this bug. ***
Comment 9 GNOME Infrastructure Team 2018-05-22 12:05:02 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-system-monitor/issues/22.