synchronize gnome applets update interval?

Thu Mar 29 06:25:55 UTC 2012

Hi Alex,
Alex Murray wrote:
> On Wed 28 Mar 2012 15:17:14 CST, Németh Márton wrote:
>> 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 panel
>>
>> 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
> 
> [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

[6] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cpu-freq/core.txt;hb=HEAD#l43

Regards,

	Márton Németh