This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1460292 - strip chart lags real time with a delay of about 5 seconds
strip chart lags real time with a delay of about 5 seconds
Status: NEW
Product: Fedora
Classification: Fedora
Component: gnome-system-monitor (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Søren Sandmann Pedersen
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2017-06-09 11:27 EDT by John Reiser
Modified: 2017-06-18 14:45 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Reiser 2017-06-09 11:27:59 EDT
Description of problem: The CPU History and Network History strip chart graphical displays of Gnome System Monitor are about 5 seconds behind real time.  By contrast, the numerical text (CPUn %, Receiving bytes/s, Sending bytes/s) are within 1 second of real time.

Version-Release number of selected component (if applicable):

How reproducible: always

Steps to Reproduce:
1. Run Activities > System Monitor on an otherwise-idle machine (bare hardware, no virtualization)
2. Start and stop a high-usage activity: such as a long scp from a nearby high-bandwidth host, or the shell script "while true; do /bin/date; done >/dev/null"  [stop with <ctrl-C>]

Actual results: Within one second the numerical text report of CPU utilization percentage goes from a couple percent [idle] to 100/N_CPU percent (around 25% on a 4-CPU machine), while the strip chart recorder does not increase until about 4  more seconds have elapsed.  The analogous lag happens when stopping the high-utilization activity.

Expected results: The strip chart and the numerical text agree, and lag at most 1 second with respect to real time.

Additional info:
Comment 1 John Reiser 2017-06-18 14:45:41 EDT
If the goal is smoothing: then display immediately, and smooth into the future.  For example, if smoothing over 5 seconds: (each second) re-calculate the 5 most recently-displayed values as the moving average going _forward_.  The value of an observation which is in the future is assumed to be equal to the most recent actual observation.  Thus a small width of the strip chart at the "active edge" will be smoothed gradually.  The value displayed on the edge will be the most recent actual observation:  (5 * value[t]) / 5. The value *displayed* for one second in the past will be (value[t-1] + 4*value[t]) / 5; for two seconds ago: (value[t-2] + value[t-1] + 3*value[t]) / 5; etc.

Note You need to log in before you can comment on or make changes to this bug.