Bug 188081

Summary: Processes in table with more than 100% are shown with 0.00%
Product: [Unmaintained] ksysguard Reporter: christoph.messer
Component: generalAssignee: KSysGuard Developers <ksysguard-bugs>
Status: RESOLVED WORKSFORME    
Severity: normal CC: johnflux, mail
Priority: NOR Keywords: triaged
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description christoph.messer 2009-03-25 14:13:28 UTC
Version:           1.2.0 (using 3.5.1 Level "a" , SUSE 10)
Compiler:          Target: x86_64-suse-linux
OS:                Linux (x86_64) release 2.6.16.60-0.34-smp

In the Process Table of ksysguard a process calculating on two CPUs (and shown with 200% in top)
is shown with User% 0.00

Expected behaviour:
Show correct load as in "top"
Comment 1 John Tapsell 2009-06-04 01:22:55 UTC
Hmm, can you offer any more details?  Not much to go on :-/
Comment 2 christoph.messer 2009-06-22 13:58:29 UTC
Not too much because I'm not a developer. Just the circumstances.
There is a finite elements simulation tool so called ABAQUS that can use more
than one processor for one job (you can configure that). In the "top" tool,
the user load is shown correctly as 200% if two processors are used (or 190% or something like that). In ksysguard the process is permanently shown with 0%.
Maybe there is a plausibility check that doesn't allow more than 100% or a variable is limited to that maximum. But in multiprocessor environments more than
100% is possible and needed.

Hope that helps,

Regards
Comment 3 Julian Steinmann 2018-04-02 16:41:49 UTC
This should no longer happen, as such environments are now much more common. Can you still reproduce this bug with the newest version of KSysGuard?
Comment 4 Andrew Crouthamel 2018-09-28 03:23:23 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 5 Andrew Crouthamel 2018-10-29 02:16:54 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!