Rt-Audio - Default CPU Freq Scaling vs globaler Erderwärmung

Hi

ich nutze Suse 11.2 (upgegraded von ursprünglich 11.2 RC 1) mit GNOME und einem Echtzeitkernel 2.6.31.6-rt19.
Gebaut habe ich diesen mit CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y, # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set, CONFIG_CPU_FREQ_GOV_PERFORMANCE=y, CONFIG_CPU_FREQ_GOV_ONDEMAND=y.

Für Echtzeit-Audio nutze ich natürlich das CPU Frequency Scaling "Performance", doch ansonsten will ich die Möglichkeit haben zu "Ondemand" wechseln zu können. "Ondemand" ist für Echtzeit-Audio ungeeignet, da es zwangsläufig zu Störungen führt. Ein Hin-und-her-booten zwischen verschiedenen Kerneln ist ausgeschlossen .

Die Frage lautet natürlich: Wie kann ich unter Suse 11.2 GNOME das CPU Frequency Scaling ändern?

Grüße
Ralf

Sollte eigentlich via Kommandozeile ganz easy gehen, 'cpufreq-set' bietet dafür die Möglichkeit. Die Syntax geht in etwa so:


Bei Dualcores kommt noch ein '-c 1'-Kommando dazu. Könnte man auch hübsch in ein Skript verpacken oder so.

Ich muss allerdings zugeben, dass ich mit 'cpufreq-set' noch nicht gearbeitet habe. 'man cpufreq-set' ist aber angenehm übersichtlich und sollte leicht zu erschließen sein.

Hi

dass ist schon mal eine Hilfe. Wer seine CPU nicht kennt, kann die benötigten Informationen durch das Kommando "cpufreq-info" in Erfahrung bringen.
Was ich benötige erreiche ich durch die Kommandos "sudo cpufreq-set -gondemand" und
"sudo cpufreq-set -gperformance".

Ein Shell-Skript erscheint mir unangebracht zu sein, jedoch habe ich Aliase angelegt:
alias cpu-o="sudo cpufreq-set -gondemand"
alias cpu-p="sudo cpufreq-set -gperformance"

Gibt es keine Möglichkeit, dass eigentlich dafür vorgesehene Panel-Applet dazu zu nutzen?

Für mein 64 Studio 3.0-beta3 kann ich dies, in Ermangelung Policy Kit nutzen zu können, durch setzen des SUID-Bits erreichen, also durch "sudo chmod u+s /usr/bin/cpufreq-selector". Diesen cpufreq-selector scheint es für Suses GNOME Panel-Applet aber nicht zu geben.

Gruß
Ralf

Ich nutze kein GNOME, aber wenn ich das richtig recherchiert habe, steckt der cpufreq-selector im Paket 'gnome-applets' (via 'oss' erhältlich).

Nur mal so nebenbei: 'sudo' ist hier genau genommen nicht ganz der richtige Befehl, auch nicht bei den alias-Kommandos (es sei denn, Deine sudoers ist entsprechend konfiguriert, siehe auch 'man sudo').


Das aber nur so nebenbei, das Ergebnis ist ja das selbe.

Habe gerade 64 Studio gebootet und werde es später mit su versuchen. Es funktioniert allerdings mit sudo, habe Suse aber nicht anders konfiguriert und sudo nur unbewusst gewählt, da ich für 64 Studio, dass auf Hardy basiert, entschieden habe keinen Root-Account anzulegen und Ubuntu bedauerlicherweise sudo etwas ungewohnt nutzt. Danke für den Hinweis.

Hi

zuerst einmal danke gropiuskalle, für den Hinweis auf die Möglichkeit das Frequency Scaling über Kommandozeile wählen zu können.

Diesen Thread sehe ich für mich als geschlossen, aber nicht zufriedenstellend gelöst an, daher "[unzufriedenstellend gelöst]", denn leben kann man damit schon.

Als Info für andere, mit dem Bedürfnis die CPU Frequenz kontrollieren zu wollen.
Dies scheint die komfortabelste Lösung zu sein:
Das Paket "gnome-applets" beinhaltet "cpufreq-selector" nicht mehr. Das Problem dürfte für die KDE-Variante "KPowersave" das selbe sein.

Mit openSUSE 11.2 hat die Philosophy in openSUSE Einzug genommen, dass der Kernel besser als der User entscheiden könne, wie die CPU zu takten sei. Für den durchschnittlichen Desktop-Nutzer ist auch nichts dagegen zu sagen, jedoch sieht es für Multimedia-Echtzeit-Nutzer anders aus.

Natürlich habe ich, wie erwähnt, meinen Kernel-rt schon mal mit "performance" statt "ondemand" gebaut. Wie dies die Kernel-rt aus den Repositories handlen weiß ich nicht, da sie den Startup bei mir abbrechen, denn angeblich ist ein Fehler auf der Festplatte, den Kernel-desktop und mein eigener -rt nicht monieren.

"Performance" ist für Multimedia-Anwendungen im Echtzeitbetrieb notwendig um Störungen bei Audiosignalen zu unterbinden, nicht aber während ein Musiker einen Text schreibt, ein Audio-Programmierer einen Fehler sucht etc., außerdem will der eine und andere sicher nicht eine Sammlung von Kerneln haben und den Kernel-rt auch für jede andere alltägliche Anwendung nutzen können und generell funktioniert "ondemand" hervorragend, solange Echtzeit für Audio ungenutzt bleibt.

Wer also Kontakte zu den Suse-Entwicklern pflegt, mag vielleicht mal darauf hinweisen, dass die Möglichkeit für User, die CPU über das GNOME-Applet oder KPowersave handlen zu können durchdacht ist und nicht durch Suse undurchdacht geändert werden sollte. Meine Kontakte beschränken sich bisher auf eine debianoide Distri.

Grüße
Ralf

Das Paket "gnome-applets" beinhaltet "cpufreq-selector" nicht mehr.

Zum Vergrößern anklicken....

Das stimmt - Pakete für die 11.0 und 11.1 (Version 2.22.1 bzw. 2.24.1) beinhalten das Ding noch, in jenen der 11.2 (2.28.0) ist das nicht mehr vorhanden.

Mit openSUSE 11.2 hat die Philosophy in openSUSE Einzug genommen, dass der Kernel besser als der User entscheiden könne, wie die CPU zu takten sei.

Zum Vergrößern anklicken....

Naja - Du sprichst hier von einem GNOME-applet, das wird jedoch nicht vom openSUSE-Team entwickelt, sondern von GNOME.

Wie dies die Kernel-rt aus den Repositories handlen weiß ich nicht, da sie den Startup bei mir abbrechen, denn angeblich ist ein Fehler auf der Festplatte, den Kernel-desktop und mein eigener -rt nicht monieren.

Zum Vergrößern anklicken....

Dem würde ich dennoch mit entsprechenden tools auf dem Grund gehen. Solche Meldungen erscheinen selten einfach so.

Wer also Kontakte zu den Suse-Entwicklern pflegt, mag vielleicht mal darauf hinweisen, dass die Möglichkeit für User, die CPU über das GNOME-Applet oder KPowersave handlen zu können durchdacht ist und nicht durch Suse undurchdacht geändert werden sollte. Meine Kontakte beschränken sich bisher auf eine debianoide Distri.

Zum Vergrößern anklicken....

Mal ganz grundsätzlich: wir sind hier ein SuSE-Forum, aber keine Durchreiche für feature-requests. Jeder kann derartige Anfragen über den Novell-bugtracker stellen. Aber wie gesagt: das Fehlen des cpufreq-selectors ist wohl eher GNOME geschuldet und nicht dem openSUSE-team (ohne Gewähr, ich kenne die jeweiligen Pakete und ihre Hintergründe nicht, schau doch mal, welche Version der gnome-applets unter 64 Studio läuft).

Davon abgesehen lässt sich sowas doch einfach bashskripten, grob umrissen: mit cpufreq-info prüfen, welches Prozessor-Profil gerade läuft, falls 'gondemand', dann auf 'gperformance' schalten oder eben umgekehrt. Ich weiß jetzt nicht, wie sich Dialoge unter GNOME erstellen lassen, aber auch derlei sollte nicht allzu schwer sein (Infofenster in der Art von "Es läuft gondemand. Umschalten? [ja] [nein] oder sowas). Das könnte man dann auch recht einfach ins Panel packen.