https://bugs.kde.org/show_bug.cgi?id=458306
Bug ID: 458306
Summary: ksysguardd reported unrealistic value for one of the
cpu/cpu,*/TotalLoad sensors
Product: ksysguard
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: ksysguardd
Assignee: ksysguard-b...@kde.org
Reporter: khaluk...@gmail.com
CC: plasma-b...@kde.org
Target Milestone: ---
Created attachment 151588
--> https://bugs.kde.org/attachment.cgi?id=151588&action=edit
screenshot
SUMMARY
On some rare occasions gsysguard receives some very high value for CPU
utilization for one of the CPU cores. That value exceeds what it can be in real
life. If user has a plot, where he prints together all the CPUs utilization
together, this sudden spike makes the plot to dynamically change its scale,
which in turn makes further readings from the plot impossible, until the spike
goes away into history and plot scale returns back to normal on its own.
See screenshot please - the insane high value came from gsysguardd was 3e+19%
IMHO, for the sensors/metrics we know the physical limit (like this one - total
load for CPU cannot physically exceed 100%) there should be some simple
protection in place, like to report the MAX value when the sensor' readings
ksysguardd gets is unreliable. Freezing the scale on front end side is the
workaround off course, but you discover this option only after this bug plays a
trick on you :)
SOFTWARE/OS VERSIONS
System monitor version 5.20.5
KDE Frameworks 5.78.0
Qt 5.15.2 (built against 5.15.2)
The xcb windowing system
ksysguard 4:5.20.5-2 arm64
ksysguardd 4:5.20.5-2 arm64
CPU is ARM RockChip RK3399
Linux kernel 5.18.5-rk3399
--
You are receiving this mail because:
You are watching all bug changes.
