Public bug reported:
Binary package hint: gnome-system-monitor
Hi! This report is about System Monitor 2.18.1.1, running on Ubuntu
Feisty. It would be a nice fix for Gutsy.
The System Monitor is a nice tool for a quick estimate of the current
CPU usage, but it could be much more useful if it actually gave a bit
more history.
First of all, the time scale is not marked. So I estimate it always
shows me approximately one minute of history, but I can't tell for sure
unless I measure it by hand. (I mentioned this in bug #109356, too.)
Second, it only starts recording the "history" from the moment I open
the window. This means that if I open the window in response to
unresponsiveness (for instance), I can't see which of the three graphs
was actually the problem (CPU, memory or network); usually the window
takes its sweet time to load, so the spike is probably gone by the time
it shows up.
Third, even if I left it open all the time to record such a spike,
there's no kind of pan & zoom, so I can't look more than a couple of
minutes in the past.
I'm entering this all together as it's a more of a wishlist (rather than
just a wish for the program's wishlist). I'd like the program to go a
bit the way of the battery monitor (and, why not, include that too; it's
a system monitor, right?), and even a bit more (pan/zoom).
I'm not sure exactly how the system monitor works, but I think a generic
"system monitor process" would be a good idea: it would run continuously
in the background, gathering all sorts of info (processor, memory, IO
usage, power statistics, battery charge, etc) at predefined frequencies
(of the top of my head, between once each second and once each minute
might be reasonable). It can save parts of it (aggregates for longer
periods) to disk, in such a way as to not consume lots of resources.
These logs would be available to the users when they open the "System
Monitor" window.
(Conservative cost estimate: 32 bits/value, 100 values monitored, 1 Hz =
~1.5 MB per hour; this could be easily kept in RAM on new machines.
However, whenever the hard drive is used we can also copy parts of it to
disc, with low priority IO, so we don't change the spin-down frequency
much. With a 100 MB hard-drive budget we could keep almost three days of
history with second-precision. Most users won't need detailed
measurement for that long in the past, so for things that go more than a
day, or even an hour, we could aggregate stuff, so we only save per-
minute statistics. So each day we'd have to input the last day's logs,
about 40 MB of saved data, aggregate it (it only takes simple averaging,
usually) and output ~ 0.7 MB for 1-minute precision, or ~140 kB for
5-minute precision. With another 100 MB, we could have these logs for 4
months (1 minute) or almost two years (5 minute). This doesn't mention
compression -- most values don't need 32 bits, and don't change randomly
all the time. I think this would be potentially very useful at little
cost (my /var/log is 25 megs, 200 is just an order of magnitude above),
and not at all intrusive for users who don't need it. And it could offer
interesting options in the long term. Just an example: it would become
feasible to actually find out how a driver update changes power usage,
by gathering the logs from users who use the driver, a month before and
after -- properly anonymized, of course -- and see if there's any
correlation. If the log contains programs used -- this is more
problematic -- we could even check how optimizations perform in the real
world.)
** Affects: gnome-system-monitor (Ubuntu)
Importance: Undecided
Status: Unconfirmed
--
The "History" graphs really need history
https://bugs.launchpad.net/bugs/109374
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
