Opened 14 years ago

Closed 11 years ago

#2141 closed enhancement (wontfix)

Memory and CPU status indicator for the frame.

Reported by: m_anish Owned by: tomeu
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: Sugar Version: Unspecified
Severity: Unspecified Keywords: r! dextrose
Cc: m_anish, bernie, dsd, silbe, mtd Distribution/OS: Unspecified
Bug Status: Unconfirmed

Description

I would be nice to have a Memory and CPU status indicator in the frame. Such an indicator would give intuitive feedback to the user through expressive frame-icon states and appropriate text/progress-bars in the palette menu.

This would be a good tool for sugar users to 'see' the results their actions have on the system resources.

Attachments (2)

Sugar-devel-Add-icons-for-memory-and-cpu-resource-indicator.patch (11.9 KB) - added by m_anish 14 years ago.
The icons used by the frame-indicator.
cpu-and-memory-resource-indicator.patch (10.3 KB) - added by m_anish 14 years ago.
Memory and CPU status indicator for the frame patch.

Download all attachments as: .zip

Change History (24)

Changed 14 years ago by m_anish

The icons used by the frame-indicator.

comment:1 Changed 14 years ago by m_anish

  • Keywords dextrose added

comment:2 follow-up: Changed 14 years ago by tomeu

  • Keywords r! added; r? removed

+ self.create_palette()

Why create the palette at this point?

+ logging.debug('palette created')

Might not be useful any more.

+ self.palette.connect('system-mood-changed',
+ self._system_mood_changed_cb)

Looks like the Palette is doing the role of the model, which is weird. Instead, we should have a Model class and both the icon and the palette would listen to it.

+ def _system_mood_changed_cb(self, gobject, mood):

Two leading underscores.

+ self.vbox = gtk.VBox()

All members should be private unless they are needed outside its class.

+ return [int(count)
+ for count in file('/proc/stat').readline().split()[1:6]]

Can we get this in separate lines with meaningfully-named intermediate variables?

+ _cpu_times_current = [(new - old)
+ for new, old in zip(_cpu_times_new, self._cpu_times)]

Same here.

+ self._cpu_text.set_label(_('CPU in use: %d%%' % cpu_in_use))

The _() should apply only to the string to be translated, see for other instances of this in the patch.

+ self._cpu_bar.set_fraction( cpu_in_use / 100.0 )

Extra spaces inside the parens, look for other instances of this.

+ # both cpu_free and memory_free lie between 0-100
+ system_mood = _SYSTEM_MOODS[
+ int( ( 200 - (cpu_in_use + memory_in_use) ) / 66.66 ) ]

Is it really better than a few simple elifs? You would also avoid the dangerous except AttributeError: below.

+ def _stop_computing_statistics(self):
+ """
+ Stop computing usage statistics and display and error message
+ since we've hit an exception.

Seems like here we are just displaying the error message?

+ self.emit('system-mood-changed', '-error')

May be better to have the moods be constants so we don't duplicate the strings?

comment:3 in reply to: ↑ 2 ; follow-up: Changed 14 years ago by m_anish

  • Keywords r? added; r! removed

Replying to tomeu:

Thanks for the review.

+ self.create_palette()

Why create the palette at this point?

The system resources are computed at 5 second intervals. So, if I create the palette when the frame is invoked and attempt to view the the resource icon's palette immediately, I'll see a palette with two empty progress-bars and no text for a few seconds. Note that this will happen only for the first time when viewing the frame icon's palette.

To overcome this, I create the palette early. So as soon as I attempt to view it for the first time, I won't see empty info as in the case above

I've incorporated all the other changes you suggested.

Changed 14 years ago by m_anish

Memory and CPU status indicator for the frame patch.

comment:4 in reply to: ↑ 3 ; follow-up: Changed 14 years ago by tomeu

  • Keywords r! added; r? removed

Replying to m_anish:

Replying to tomeu:

Thanks for the review.

+ self.create_palette()

Why create the palette at this point?

The system resources are computed at 5 second intervals. So, if I create the palette when the frame is invoked and attempt to view the the resource icon's palette immediately, I'll see a palette with two empty progress-bars and no text for a few seconds. Note that this will happen only for the first time when viewing the frame icon's palette.

To overcome this, I create the palette early. So as soon as I attempt to view it for the first time, I won't see empty info as in the case above

Maybe I'm missing something: why not compute the data when the palette is first displayed, then update it every 5 seconds until the palette is closed?

comment:5 in reply to: ↑ 4 ; follow-up: Changed 14 years ago by m_anish

  • Keywords r? added; r! removed

Replying to tomeu:

Replying to m_anish:

Replying to tomeu:

Thanks for the review.

+ self.create_palette()

Why create the palette at this point?

The system resources are computed at 5 second intervals. So, if I create the palette when the frame is invoked and attempt to view the the resource icon's palette immediately, I'll see a palette with two empty progress-bars and no text for a few seconds. Note that this will happen only for the first time when viewing the frame icon's palette.

To overcome this, I create the palette early. So as soon as I attempt to view it for the first time, I won't see empty info as in the case above

Maybe I'm missing something: why not compute the data when the palette is first displayed, then update it every 5 seconds until the palette is closed?

There are two reasons for this

==Reason 1==

Its because of the way the resource usage numbers are acquired. Memory usage can be computed instantaneously by reading /proc/meminfo.

However, CPU usage cannot be computed instantaneously. It is computed by finding the difference in /proc/stat numbers between two snapshots (which, in this case are 5 seconds apart). Thus, if I were to start my CPU usage computation the moment the palette is made visible, something like this would happen:

1) Palette invoked/made visible

2.a) Compute memory usage
2.b) Start computing CPU usage -> take initial /proc/stat snapshot

... 5 seconds later ...

3) Take 2nd /proc/stat snapshot. From difference between two snapshots, compute CPU usage
4) Update palette with CPU and memory usage numbers (Until this time, the palette would display two empty progress bars)

Note: This problem of an 'empty' palette will happen only for the very first time when viewing the palette. Every subsequent time, the palette would contain meaningful data whenever visible.

==Reason 2==

Also, unlike the previous versions of this patch, I am dynamically changing the frame icon based on current available resources. This way, a user can simply make the frame visible and get an abstract idea of system resources just by looking at the icon which would either be normal, happy or sad (or error when an exception happens), much like visual feedback the speaker or network icons provide. It is another reason why I cannot limit my resource-usage computation to the palette-is-visible time window.

comment:6 in reply to: ↑ 5 ; follow-up: Changed 14 years ago by tomeu

Replying to m_anish:

There are two reasons for this

==Reason 1==

'top' only waits 0.5s. by default. What about gathering the initial statistics for that period then updating every 5s from now on?

==Reason 2==

Well, the icon should also only be updated when it is visible.

In any case, if people such as Bernie and Daniel Drake are ok with this, I don't have any problem in accepting it.

comment:7 in reply to: ↑ 6 Changed 14 years ago by bernie

Replying to tomeu:

In any case, if people such as Bernie and Daniel Drake are ok with this, I don't have any problem in accepting it.

We did all the field testing with the present version of the patch. As far as I'm concerned, the current behavior is generally good enough and heuristics could always be refined later on.

As tomeu suggested, it might make sense to reduce the weight of the CPU in the formula for computing the load, so that we couldn't go sad just because the CPU is in use. Going serious should be enough, imho.

comment:8 follow-ups: Changed 14 years ago by tomeu

  • Keywords r! added; r? removed

Have given it a go in my machine and have been thinking a bit about it, and I'm quite unsure we can find a set of parameters that work well in all the scenarios where Sugar is expected to run. Consider for example a LTSP environment where all the Sugar instances share the same address space.

I'm also concerned that we are going to pay a penalty for updating the CPU usage when we agreed that the important measure is memory.

There has been some discussion about this in #sugar involving Daniel and Bernie, Anish, have you read it?

I think work like this belongs better outside the sugar source tree until we agree this is of general interest to all the users we are targeting. I know XOs are our most important use base by large, but we still aim to grow to other areas. Extensions exist precisely so people can extend the Sugar shell without having to either patch or go through all the submission process, I don't think we should try to upstream everything.

comment:9 in reply to: ↑ 8 Changed 14 years ago by bernie

Replying to tomeu:

I think work like this belongs better outside the sugar source tree until we agree this is of general interest to all the users we are targeting. I know XOs are our most important use base by large, but we still aim to grow to other areas. Extensions exist precisely so people can extend the Sugar shell without having to either patch or go through all the submission process, I don't think we should try to upstream everything.

Fine with me. Indeed, the indicator is mostly useful on platforms that are very resource constrained, such as the XO.

comment:10 in reply to: ↑ 8 ; follow-up: Changed 14 years ago by sascha_silbe

Replying to tomeu:

Have given it a go in my machine and have been thinking a bit about it, and I'm quite unsure we can find a set of parameters that work well in all the scenarios where Sugar is expected to run. Consider for example a LTSP environment where all the Sugar instances share the same address space.

The combined display ("mood") might not work too well on systems with lots of RAM, but other than that I fail to see why the proposed device icon would fail to be useful on a wide range of systems. Even for single-user systems the resource usage isn't entirely up to the user to control (e.g. cron jobs); but that doesn't imply it doesn't matter to know about current resource usage.
The palette shows cumulative resource usage as a fraction, so there's no dependency on particular hardware specs like memory size, number of CPUs or CPU frequency.

I'm also concerned that we are going to pay a penalty for updating the CPU usage when we agreed that the important measure is memory.

Another important measure is IO-wait. IIRC the CPU calculation was chosen to reflect this, so the CPU part shouldn't be dropped.

I think work like this belongs better outside the sugar source tree until we agree this is of general interest to all the users we are targeting. I know XOs are our most important use base by large, but we still aim to grow to other areas.

I have to disagree. On all systems I've used so far, knowing about current resource usage is important. I use top about once a day on average, including on my dual-core, 1.9GHz workstation with 4GB of RAM.

Extensions exist precisely so people can extend the Sugar shell without having to either patch or go through all the submission process, I don't think we should try to upstream everything.

If you don't want this to be enabled by default, please at least ship it in a "contrib" directory so enabling it is as easy as creating a symlink.
The clock device icon could ship in the same directory then. It's the #1 reason I bring up the Frame (#2 is wifi status).

comment:11 in reply to: ↑ 10 ; follow-up: Changed 14 years ago by tomeu

Replying to sascha_silbe:

If you don't want this to be enabled by default, please at least ship it in a "contrib" directory so enabling it is as easy as creating a symlink.
The clock device icon could ship in the same directory then. It's the #1 reason I bring up the Frame (#2 is wifi status).

Sounds an interesting idea.

comment:12 in reply to: ↑ 11 ; follow-up: Changed 14 years ago by bernie

Replying to tomeu:

Replying to sascha_silbe:

If you don't want this to be enabled by default, please at least ship it in a "contrib" directory so enabling it is as easy as creating a symlink.
The clock device icon could ship in the same directory then. It's the #1 reason I bring up the Frame (#2 is wifi status).

Sounds an interesting idea.

How about shipping both these extensions in the regular extensions folder, but with a gconf key to enable them?

I already envision a TweakUi activity which, I bet, would be *VERY* popular among children :-)

comment:13 in reply to: ↑ 12 ; follow-up: Changed 14 years ago by tomeu

Replying to bernie:

Replying to tomeu:

Replying to sascha_silbe:

If you don't want this to be enabled by default, please at least ship it in a "contrib" directory so enabling it is as easy as creating a symlink.
The clock device icon could ship in the same directory then. It's the #1 reason I bring up the Frame (#2 is wifi status).

Sounds an interesting idea.

How about shipping both these extensions in the regular extensions folder, but with a gconf key to enable them?

I already envision a TweakUi activity which, I bet, would be *VERY* popular among children :-)

I personally don't care much about it, but I think deployers and QA people should be quite concerned about the costs of users being able to change the UX significantly and easily. May be better to discuss it now and figure out some rules about when to use GConf keys than later having to roll back changes that may have proven popular in the field but too expensive to support.

comment:14 in reply to: ↑ 13 ; follow-up: Changed 14 years ago by bernie

Replying to tomeu:

I personally don't care much about it, but I think deployers and QA people should be quite concerned about the costs of users being able to change the UX significantly and easily. May be better to discuss it now and figure out some rules about when to use GConf keys than later having to roll back changes that may have proven popular in the field but too expensive to support.

I agree with your argument, but consider that:

1) we claim that users can freely modify even the code. If they currently can't, it's mostly because our UX is incomplete.

2) when given the opportunity, many children are switching to GNOME also because of its UI customization options, such as setting a background picture or choosing a screensaver. As useless as these things may seem, humans of all ages seem to like them, including hackers. (my desktop background is all black, I would refuse to use a computer which comes with a blue sky over a green grass theme ;-).

comment:15 in reply to: ↑ 14 ; follow-up: Changed 14 years ago by m_anish

  • Cc dsd silbe added

Replying to bernie:

Replying to tomeu:

I personally don't care much about it, but I think deployers and QA people should be quite concerned about the costs of users being able to change the UX significantly and easily. May be better to discuss it now and figure out some rules about when to use GConf keys than later having to roll back changes that may have proven popular in the field but too expensive to support.

I agree with your argument, but consider that:

1) we claim that users can freely modify even the code. If they currently can't, it's mostly because our UX is incomplete.

2) when given the opportunity, many children are switching to GNOME also because of its UI customization options, such as setting a background picture or choosing a screensaver. As useless as these things may seem, humans of all ages seem to like them, including hackers. (my desktop background is all black, I would refuse to use a computer which comes with a blue sky over a green grass theme ;-).

Since this discussion has broadened in concept, should we move over to sugar-devel?

Regarding this particular ticket/patch, these are the points of contention -

  1. Don't include CPU usage numbers.
  2. Include CPU numbers, but lower its weight-age in determining the 'mood'.
  3. Use /proc/loadavg instead of /proc/stat. This way we can compute CPU usage instantaneously.

What do you think reg. the above?

comment:16 in reply to: ↑ 15 Changed 14 years ago by bernie

Replying to m_anish:

Regarding this particular ticket/patch, these are the points of contention -

  1. Don't include CPU usage numbers.
  2. Include CPU numbers, but lower its weight-age in determining the 'mood'.
  3. Use /proc/loadavg instead of /proc/stat. This way we can compute CPU usage instantaneously.

What do you think reg. the above?

Regarding (2), I'm no longer so sure we should change the weight of the CPU. Using 100% of processor time is definitely an improper thing to do for an activity. It slows down the machine and draws a lot more power. Therefore, should reflect this problem in the frame icon. On the XO-1.5, and other machines with plenty of memory, 100% of CPU is already not sufficient by itself to make our tamagochi cry. If it's enough on the XO-1, it's only because the overall situation is *really* much worse.

I would give a try to (3) to see if it's really viable. It works well for xload.

That said, I'd encourage everyone not to aim at getting this code perfect before allowing it in. A patch that improving the current situation is already a big step forward. Heuristics can always be refined and improved by later patches, possibly submitted by those who are unhappy with the behavior on their particular platform.

As Jim Gettys would say, perfect is the enemy of good.

comment:17 Changed 14 years ago by bernie

Ping? This bug has been stuck for 2 weeks.

comment:18 follow-up: Changed 14 years ago by garycmartin

As a general design related comment, I see the CPU status indicators value for a certain type of user/tester/qa on XO hardware, but worry about having it added to the Sugar UI permanently for all our target users. I do not see such features added to other OS/platforms except optionaly for when performing administration and testing tasks. The device icon is 'cute' but does increase the UI complexity/clutter and very much reminds me of the start of menu extras (OSX) and task bar extras (Windows) feature creep wars, setting a trend for bolting on extras, rather than trying to fix the underlying issue (in this case kernel OOM behaviour, an unclear activity multitasking UI).

comment:19 in reply to: ↑ 18 Changed 14 years ago by bernie

Replying to garycmartin:

As a general design related comment, I see the CPU status indicators value for a certain type of user/tester/qa on XO hardware, but worry about having it added to the Sugar UI permanently for all our target users. I do not see such features added to other OS/platforms except optionaly for when performing administration and testing tasks. The device icon is 'cute' but does increase the UI complexity/clutter and very much reminds me of the start of menu extras (OSX) and task bar extras (Windows) feature creep wars, setting a trend for bolting on extras, rather than trying to fix the underlying issue (in this case kernel OOM behaviour, an unclear activity multitasking UI).

I think you're mistaking this feature for eye candy or a geek toy.

It is quite the opposite: we don't need a smiley face to tell us how much resources are left in the system because we're always aware of it. After years of Linux usage, I can "sense" swappiness when interacting with the system even without the aid of an HD led.

However, for young children and teachers it's a different story: when they complain about the system not working well, I almost always find 3-4 open activities in the frame. Then I close the ones they don't need and politely explain that there's an invisible quantity called "memory" that becomes full if you open many "large" activities and another invisible quantity called "cpu time" that gets consumed by some activities such as Measure and eToys.

They smile, without actually understanding my explanation. I know that tomorrow they will keep opening activities without regard to the system resources that they cannot see or quantify.

This is why we commissioned the resource monitor to Anish. Teachers and children like it very much. They understand this advanced concept without explanation and they learn to manage their computer rationally in the face of very limited resources.

Btw: http://wiki.sugarlabs.org/go/File:Dextrose_resource_monitoring.png

[PS: I hate discussing these things in the bug tracker, where there's no proper threading and only few people can participate. Please, let's move to the mailing list.]

comment:20 follow-up: Changed 13 years ago by mtd

  • Cc mtd added

Can someone summarise the status of discussion on the mailing list? Have we decided in favour?

comment:21 in reply to: ↑ 20 Changed 13 years ago by m_anish

Replying to mtd:

Can someone summarise the status of discussion on the mailing list? Have we decided in favour?

I'll give it a go...

  1. The heuristic for calculating the system load could be better.
  2. Martin Langhoff (and others) suggested that instead of portraying the computer as happy/normal/sad, an empty/full metaphor would be better.
  3. It was debated whether the cpu load/status should be included in determining the mood at all.

*

  1. A forked-thread on the m.l. also discusses the possibility of integrating other system parameters (for example, battery, system temperature, available storage space) into the 'system mood'
  2. There were arguments both in favor and against it. There was concern that oversimplifying things to such an extent wouldn't solve anything. Walter mentioned that the possibility of making the XO kid in the center of the screen behave like a Tamagotchi had been discussed before.
  3. Someone also suggested writing an activity just to plot the various system parameters.

*

Have we decided in favor? Well I guess it isn't a simple yes/no, but in its present form, the patch won't be upstreamed. The patch, however, would be included in all dextrose builds and has received good feedback from deployment.

Please add/correct if I missed anything.

comment:22 Changed 11 years ago by dnarvaez

  • Resolution set to wontfix
  • Status changed from new to closed

Please bring the discussion on the ml and open a ticket if there is consensus we should add this. (Assuming it has not been added already :P Can't test atm sorry).

Note: See TracTickets for help on using tickets.