synchronize gnome applets update interval?

[Németh Márton]

Hi Aley, 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

[Alex Murray]

Post by Németh Márton
Hi Aley, Carlos, Martin, Todd, Benoît and Davyd,
- 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.
$ lsb_release -a
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

[Németh Márton]

Hi Alex,

Hi Alex, Carlos, Martin, Todd, Beno=C3=AEt and Davyd,
I'm using your gnome applets to monitor the following things on my l=
- CPU temperature (sensors-applet, http://sensors-applet.sourcefor=

ge.net/ )

- CPU usage (multiload-applet-2)
- CPU frequency (cpufreq-applet)
My primary goal is to keep the CPU fan quiet as far as possible. Thi=

s 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/powerto=

p/ )

to see what processes are causing wakeups. I realized that the apple=

ts 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 updat=

e 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 on=

ce 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 ap=

plets

so that they wakes up one after the other causing only one wakeup ev=

ery 5 seconds.

$ lsb_release -a
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:deskto=
p-3.1-ia32:desktop-3.1-noarch:desktop-3.2-ia32:desktop-3.2-noarch:graph=
ics-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-no=
arch: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=3DUnknown/Install/Remove/Purge/Hold
| Status=3DNot/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWa=

it/Trig-pend

|/ Err?=3D(none)/Reinst-required (Status,Err: uppercase=3Dbad)
||/ Name Version =

Description

+++-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D-=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D

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=C3=A1rton N=C3=A9meth

=20
Hi M=C3=A1rton,
=20
Thankfully you needn't worry too much about unsynchronised wakeups=20
since the glib developers already thought of this and there exists th=

e=20

function g_timeout_add_seconds() [1] which causes the wakeups to occu=

r=20

in whole second amounts AT whole second intervals - so multiple wakeu=

ps=20

are synchronised for exactly the reason you want.
=20
sensors-applet already uses this [2] as does cpufreq [3] however it=20
looks like multiload doesn't [4] - but a simple patch to change this =

to=20

the seconds variant shouldn't be too hard and should then allow all 3=

=20

to be in sync (as far as I can tell).
=20
Cheers
Alex
=20
[1]=20
http://developer.gnome.org/glib/2.30/glib-The-Main-Event-Loop.html#g-=

timeout-add-seconds-full

[2]=20
http://sensors-applet.git.sourceforge.net/git/gitweb.cgi?p=3Dsensors-=

applet/sensors-applet;a=3Dblob;f=3Dsensors-applet/sensors-applet.c;h=3D=
e9801a05f2be8631c2bfa59ed299e338a7be57c5;hb=3DHEAD#l1415

[3]=20
http://git.gnome.org/browse/gnome-applets/tree/cpufreq/src/cpufreq-mo=

nitor.c#n319

[4]=20
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 rep=
laced with g_timeout_add_seconds_full()
- multiload uses g_timeout_add(): if the interval parameter is multipl=
e of 1000ms
then the g_timeout_add_seconds_full() can be used.

The function g_timeout_add_seconds_full() [1] solves the problem when d=
ifferent
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. W=
orst case
I can have the following scenario with three applets, each of them is s=
et up to
5000ms refresh time assuming all of them uses g_timeout_add_seconds_ful=
l():

t =3D 0ms: sensors-applet runs
t =3D 1000ms: cpufreq-monitor runs
t =3D 2000ms: multiload runs
t =3D 3000ms: IDLE
t =3D 4000ms: IDLE
t =3D 5000ms: sensors-applet runs
t =3D 6000ms: cpufreq-monitor runs
t =3D 7000ms: multiload runs
t =3D 8000ms: IDLE
t =3D 9000ms: IDLE
t =3D 10000ms: sensors-applet runs
=2E..

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 ge=
neral
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 giv=
e a good
overview on a given system.

Another thing is that in case of the cpufreq-monitor applet, which disp=
lays
the actual CPU frequency the polling is not the most efficient way disp=
laying this
information. Assuming that the "ondemand" CPU frequency scaling governo=
r 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 kno=
w if this
kind of information is available for user-space processes, maybe the CP=
UFreq
notifiers [6] can be used for this?

[5] http://en.wikipedia.org/wiki/Greatest_common_divisor

[6] http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;=
a=3Dblob;f=3DDocumentation/cpu-freq/core.txt;hb=3DHEAD#l43

Regards,

M=C3=A1rton N=C3=A9meth
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html