GNOME Bugzilla – Bug 526071
Update Interval is not in seconds
Last modified: 2018-06-20 12:20:59 UTC
Please describe the problem: In the Edit > Preferences window, in the Resources tab, there is a setting for the update interval. Though it is specifically called "Update interval in seconds," the graphs do not follow that. The labeling of the graphs is accurate, but they update more often than they are set to. I have had to set my value to 5 to get an interval of about a second. Steps to reproduce: 1. Set the update interval to 1 2. 3. Actual results: Graphs update more than once a second. Expected results: Graphs update once a second. Does this happen every time? Yes. Other information: This bug is filed in Ubuntu here: https://bugs.launchpad.net/ubuntu/+source/gnome-system-monitor/+bug/205362
I understand what you mean: the graph is re-drawn / updated more frequently than the "update interval". But if you look closely, with a stop-watch, you should see that the time-scale is right.
Yes, as I said, the labeling is right, but the update interval is not.
I was going to report the same thing, but Benoit is right. If you set the update interval to 1 sec, the actual numbers are updated once a second, but the graph is updated 5 times a second. Since the graph is interpolated it looks like it's changing very rapidly. However. the code that updates the graph might need some performance improvements. On my laptop (Core 2 Duo, I945) xorg draws about 30% of one cpu when the system monitor is at the default size and the resource tab is open. If I maximize the window that number increases to 70% (1 sec update interval). That seems too much and makes the whole cpu graph pretty useless since it is mainly measuring the cpu requirement of drawing itself...
Yep, it's interpolated, but the data is really updated at the configured interval. That's a label problem. We're still looking why X uses so much CPU on some config/drivers.
So it takes a measurement at the selected time, but it updates the graph differently. I don't think they should be different like that.
Indeed, the refresh rate / interval of the graphs seems to be ~5 times. This is not intuitive. I also expected to see the refresh rate match the interval rate that I set in Preferences. Labeling is correct but also very odd (e.g. for 5 seconds: 0, 49, 97, 145, etc...) is a not a practical scale.
The scale has been fixed in 2.22.1 and should be easier to read.
I'm running 2.22.1 and in my Graph preferences the refresh is set to 10 seconds and the graphs now update every 1 second. Also the time scale matches the 1 second. As said above, when setting a refresh interval, you'd expect to see the graph update every x seconds with a cpu usage value which is being read in that same interval of x seconds as the graph update.
I don't get how we're suppose to do it righ: if we move the graph only every second, you call it jumpy. And the other way, you complain about seconds not being seconds. Someone please advise a better label for the configuration dialog.
I don't think if someone wanted the graph moved every second they would then call it jumpy. And I think when it says seconds, it should mean seconds. I think that it should behave how it is labeled. Then you could set it to zero to have it update constantly for people that think it's jumpy, and all other values would be in real seconds.
benoit, you are mixing 2 things. One is the refresh of the screen (the redrawing of the graph) and the other thing is the time scale. I think it is a very good idea to have the scale adjusted based on the refresh rate. The faster the updates, the higher scale value (longer in time) you want to give it right? But if you label an option "refresh rate in seconds" then what is that option supposed to do for you? Currently the value that a user types in does not match the redraw rate of the graph and does not match the time scale. What should be the result of the value 10 for example? If you look at the refresh rate of the system monitor docking applet then it does this correctly. With the only difference that you set its refresh rate in milliseconds.
The multiload applet graph jumps every refresh_rate. system-monitor graph implementation now has two different rates: - the redraw rate - the data refresh rate
why not update the graph every time you refresh the data? Read a value -> show the value. If you want to see the graph slide then this will be a different implementation I think. Then you'd have to divide the space between 2 subsequent measure points on the graph, with your data refresh rate and use that as your redraw rate for the graph. Ex. If the data refresh rate is 1 second, then you would like to see a new measure point appear on the graph every 1 second. If the space between one measure point and the next is 10 pixels then you'd refresh the graph every 100 milliseconds (1 second / 10 pixels) so that the graph moves up visually 1 pixel at a time which you need for the slide effect. By playing with the time scale you can make it so that it always refreshes at for example 100 milliseconds. Whatever would be comfortable for xorg :)
(In reply to comment #13) > why not update the graph every time you refresh the data? Read a value -> show > the value. and the day after, many people would come because the graph got jumpy. > > If you want to see the graph slide then this will be a different implementation > I think. Then you'd have to divide the space between 2 subsequent measure > points on the graph, with your data refresh rate and use that as your redraw > rate for the graph. that's what cairo does for us: interpolation.
(In reply to comment #14) > (In reply to comment #13) > > why not update the graph every time you refresh the data? Read a value -> show > > the value. > > and the day after, many people would come because the graph got jumpy. Did people already complain about it being jumpy? And was that complaint related to the graph refresh or to the interpolation that you mentioned below. Do people complain about the docking applet showing a jumpy graph? > > If you want to see the graph slide then this will be a different implementation > > I think. Then you'd have to divide the space between 2 subsequent measure > > points on the graph, with your data refresh rate and use that as your redraw > > rate for the graph. > > that's what cairo does for us: interpolation. Oh, if that is supposed to be working at this moment then that is jumpy indeed. But the graph redraw isn't always done at the same speed so there is definitely something wrong. Regardless of the above, there is an option in the graph preferences. It says refresh interval in seconds. Anyone would expect that if you set it to 1 that it shows an updated graph every 1 second. Set it to 10 and you expect it to update the graph every 10 seconds. How it works now is that when you set it to 100, it updates the graph every 10 seconds. If you set it to 10 then it updates the graph every 1 second. Somewhere in the code there must be a divide by 10 and that is a bug right?
(In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #13) > > > why not update the graph every time you refresh the data? Read a value -> show > > > the value. > > > > and the day after, many people would come because the graph got jumpy. > > Did people already complain about it being jumpy? And was that complaint > related to the graph refresh or to the interpolation that you mentioned below. Yup and that's when Karl provided the new sliding implementation. > Do people complain about the docking applet showing a jumpy graph? > > > > If you want to see the graph slide then this will be a different implementation > > > I think. Then you'd have to divide the space between 2 subsequent measure > > > points on the graph, with your data refresh rate and use that as your redraw > > > rate for the graph. > > > > that's what cairo does for us: interpolation. > > Oh, if that is supposed to be working at this moment then that is jumpy indeed. > But the graph redraw isn't always done at the same speed so there is > definitely something wrong. That's a different bug that should be fixed. > Regardless of the above, there is an option in the graph preferences. It says > refresh interval in seconds. "Sampling rate" then ? > Anyone would expect that if you set it to 1 that > it shows an updated graph every 1 second. Set it to 10 and you expect it to > update the graph every 10 seconds. > > How it works now is that when y²ou set it to 100, it updates the graph every 10 > seconds. If you set it to 10 then it updates the graph every 1 second. > > Somewhere in the code there must be a divide by 10 and that is a bug right? > no no no. That's the difference between the frame rate and the data sampling rate.
Some hints that might help debugging: The FIRST and SECOND refreshes happens at the correct interval. Steps to reproduce: - Open up System Monitor and switch to Resource tab - Set the interval to 10,00 (using the buttons, not keyboard - theres another bug associated with keyboard input) - Click Close (the dialog box) - Note that actual refresh now is 1s - Close the program - Open it again and just watch - The FIRST refresh takes 10 seconds to happen. You can notice that by CPU % box change - The SECOND refresh takes another 10 seconds to happen. You can notice that by CPU % box change - The THIRD and all subsequent refreshes now take only 1s The offset is confirmed to be 10 times faster. This behavior might be caused by a locale misreading of textbox value. In some locales (like Brazil), the decimal placeholder is "," (comma), NOT "." (period). So "10,00" = 10 and "10.00" = 1000. As in the US its the opposite, a value input of "10,00" in a PT-BR locale computer may be read and erroneously converted by internal functions as "1000", according to EN-US locale. And, as max value of this field is 99, maybe it is converting all values above 100 to MILLISECONDS instead of seconds, thus resulting in 1000 milliseconds = 1 second. So the problem may be just the software is unaware and not respecting system locale. Its a wild guess, but who knows ? My 2 cents...
[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.]
-- 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/20.