synchronize gnome applets update interval?
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Alex,
Quoted 66 lines · Alex Murray
Quoted 44 lines · Németh Márton
Hi Alex, Carlos, Martin, Todd, Benoît and Davyd,
I'm using your gnome applets to monitor the following things on my laptop:
- CPU temperature (sensors-applet, http://sensors-applet.sourceforge.net/ )
- CPU usage (multiload-applet-2)
- CPU frequency (cpufreq-applet)My primary goal is to keep the CPU fan quiet as far as possible. This can be achieved if the CPU temperature is kept low which depends on the CPU usage and on CPU frequency.
Then I run powertop 1.13 ( http://www.lesswatts.org/projects/powertop/ ) to see what processes are causing wakeups. I realized that the applets I run in order to have an overview on the CPU usage causes additional CPU wakeups.
So I modified the refresh interval of sensors-applet to 5.0s.
The cpufreq-applet does not have any possibility to reduce the update interval. I also modified the default update interval of multiload-applet-2 to 5000ms.As you can see I can set up two of the applets to wake up the CPU once in 5 seconds, but these two alone will wake up the CPU worst case every 2.5 seconds.
I don't know if there is any possibility to synchronize the gnome applets so that they wakes up one after the other causing only one wakeup every 5 seconds.
Here is the list of software versions I used:
$ lsb_release -a LSB Version: core-2.0-ia32:core-2.0-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch:cxx-3.0-ia32:cxx-3.0-noarch:cxx-3.1-ia32:cxx-3.1-noarch:cxx-3.2-ia32:cxx-3.2-noarch:desktop-3.1-ia32:desktop-3.1-noarch:desktop-3.2-ia32:desktop-3.2-noarch:graphics-2.0-ia32:graphics-2.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch:graphics-3.1-ia32:graphics-3.1-noarch:graphics-3.2-ia32:graphics-3.2-noarch:qt4-3.1-ia32:qt4-3.1-noarch Distributor ID: Debian Description: Debian GNU/Linux 6.0.4 (squeeze) Release: 6.0.4 Codename: squeeze $ dpkg -l gnome-power-manager gnome-applets sensors-applet Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description +++-================================-================================-================================================================================ ii gnome-applets 2.30.0-3 Various applets for the GNOME panel - binary files ii gnome-power-manager 2.32.0-2 power management tool for the GNOME desktop ii sensors-applet 2.2.5-4 Display readings from hardware sensors in your Gnome panelQuoted 4 lines
Regards,
Márton Németh
Hi Márton,
Thankfully you needn't worry too much about unsynchronised wakeups since the glib developers already thought of this and there exists the function
g_timeout_add_seconds()[1] which causes the wakeups to occur in whole second amounts AT whole second intervals - so multiple wakeups are synchronised for exactly the reason you want.sensors-applet already uses this [2] as does cpufreq [3] however it looks like multiload doesn't [4] - but a simple patch to change this to the seconds variant shouldn't be too hard and should then allow all 3 to be in sync (as far as I can tell).
Cheers
Alex
Quoted 8 lines
[1]
http://developer.gnome.org/glib/2.30/glib-The-Main-Event-Loop.html#g-timeout-add-seconds-full
[2]
http://sensors-applet.git.sourceforge.net/git/gitweb.cgi?p=sensors-applet/sensors-applet;a=blob;f=sensors-applet/sensors-applet.c;h=e9801a05f2be8631c2bfa59ed299e338a7be57c5;hb=HEAD#l1415
[3]
http://git.gnome.org/browse/gnome-applets/tree/cpufreq/src/cpufreq-monitor.c#n319
[4]
http://git.gnome.org/browse/gnome-applets/tree/multiload/load-graph.c#n377
Thanks for your quick and into deep description of this question.
Reading [1] rises some more questions for me. To summarize:
- sensors-applet uses g_timeout_add_seconds() [2], shouldn't it use g_timeout_add_seconds_full()?
- cpufreq-monitor uses g_timeout_add_seconds() [3], this has to be replaced with g_timeout_add_seconds_full()
- multiload uses g_timeout_add(): if the interval parameter is multiple of 1000ms
then the g_timeout_add_seconds_full() can be used.
The function g_timeout_add_seconds_full() [1] solves the problem when different applets are required to run at 1000ms intervals. As I can see, however, this does not solve the case when the interval is set up for example to 5000ms. Worst case I can have the following scenario with three applets, each of them is set up to 5000ms refresh time assuming all of them uses g_timeout_add_seconds_full():
t = 0ms: sensors-applet runs
t = 1000ms: cpufreq-monitor runs
t = 2000ms: multiload runs
t = 3000ms: IDLE
t = 4000ms: IDLE
t = 5000ms: sensors-applet runs
t = 6000ms: cpufreq-monitor runs
t = 7000ms: multiload runs
t = 8000ms: IDLE
t = 9000ms: IDLE
t = 10000ms: sensors-applet runs
...
So in a 10 second interval the system will wake up six times instead of two. This problem leads us to the "gratest common divider" problem [5] in general cases.
By the way, do you know about an applet which can query the registered processes which used the g_timeout_add*() functions from glib and show a graph or a text representation when they are due (like above)? This could give a good overview on a given system.
Another thing is that in case of the cpufreq-monitor applet, which displays the actual CPU frequency the polling is not the most efficient way displaying this information. Assuming that the "ondemand" CPU frequency scaling governor is active the CPU will only scale up if there is a load on the CPU. This happens when the CPU is active. The frequency downscaling is also happening when the CPU is active. So in the kernel there is an exact place when this happens. I don't know if this kind of information is available for user-space processes, maybe the CPUFreq notifiers [6] can be used for this?
[5] http://en.wikipedia.org/wiki/Greatest_common_divisor
Regards,
Márton Németh