[CfT] powerd++ 0.4.0 release candidate 1

Kamikaze

Warrior of Sunlight
Teammitglied
Ich suche Tester für das nächste powerd++ release:

https://github.com/lonkamikaze/powerdxx/releases/tag/0.4.0-rc1

Der Daemon powerd++ ist ein Ersatz für powerd aus dem Basissystem und dient dazu den CPU Takt anhand der Laststatistik zu regelen. Der Regelalgorithmus von powerd++ ist darauf ausgelegt auch mit Multicore Systemen gut zu funktionieren.

Download, Build, Install:
Code:
> fetch -o powerdxx-0.4.0-rc1.tar.gz https://github.com/lonkamikaze/powerdxx/archive/0.4.0-rc1.tar.gz
fetch: https://github.com/lonkamikaze/powerdxx/archive/0.4.0-rc1.tar.gz: size of remote file is not known
powerdxx-0.4.0-rc1.tar.gz                               74 kB  266 kBps    01s
> tar -xf powerdxx-0.4.0-rc1.tar.gz
> cd powerdxx-0.4.0-rc1
> make
c++  -O2 -pipe -std=c++14 -Wall -Werror -pedantic -c /usr/home/kamikaze/powerdxx-0.4.0-rc1/src/powerd++.cpp -o powerd++.o
c++  -O2 -pipe -std=c++14 -Wall -Werror -pedantic -c /usr/home/kamikaze/powerdxx-0.4.0-rc1/src/clas.cpp -o clas.o
c++ -O2 -pipe -std=c++14 -Wall -Werror -pedantic powerd++.o clas.o -lutil -o powerd++
c++  -O2 -pipe -std=c++14 -Wall -Werror -pedantic -c /usr/home/kamikaze/powerdxx-0.4.0-rc1/src/loadrec.cpp -o loadrec.o
c++ -O2 -pipe -std=c++14 -Wall -Werror -pedantic loadrec.o clas.o -o loadrec
c++ -O2 -pipe -std=c++14 -Wall -Werror -pedantic -fPIC -c /usr/home/kamikaze/powerdxx-0.4.0-rc1/src/loadplay.cpp -o loadplay.o
c++ -O2 -pipe -std=c++14 -Wall -Werror -pedantic loadplay.o -lpthread -shared -o libloadplay.so
> doas make install
Password:
install  -s -m 555 /usr/home/kamikaze/powerdxx-0.4.0-rc1/obj/powerd++ /usr/local/sbin/powerd++
install  -l s powerd++ /usr/local/sbin/powerdxx
install  -s -m 555 /usr/home/kamikaze/powerdxx-0.4.0-rc1/obj/loadrec /usr/local/bin/loadrec
install  -m 555 /usr/home/kamikaze/powerdxx-0.4.0-rc1/loadplay.sh /usr/local/bin/loadplay
install  -s -m 444 /usr/home/kamikaze/powerdxx-0.4.0-rc1/obj/libloadplay.so /usr/local/lib/libloadplay.so
install  -m 444 /usr/home/kamikaze/powerdxx-0.4.0-rc1/README.md /usr/local/share/doc/powerdxx/README.md
install  -m 444 /usr/home/kamikaze/powerdxx-0.4.0-rc1/man/powerd++.8 /usr/local/man/man8/powerd++.8.gz
install  -l s powerd++.8.gz /usr/local/man/man8/powerdxx.8.gz
install  -m 444 /usr/home/kamikaze/powerdxx-0.4.0-rc1/man/loadrec.1 /usr/local/man/man1/loadrec.1.gz
install  -m 444 /usr/home/kamikaze/powerdxx-0.4.0-rc1/man/loadplay.1 /usr/local/man/man1/loadplay.1.gz
install  -m 555 /usr/home/kamikaze/powerdxx-0.4.0-rc1/powerd++.rc /usr/local/etc/rc.d/powerdxx
>

Alternativ zur Installation können die Binaries direkt nach dem make aus obj/ ausgeführt werden.

Neu in 0.4.0:

- Startet endlich auch wenn Hyperthreading in der /boot/loader.conf deaktiviert ist
- loadrec funktioniert jetzt auch bei laufendem powerd/powerd++
- loadplay wurde überarbeitet
 
Zuletzt bearbeitet:
Ich würde noch dazu schreiben, was dieses powerd++ eigentlich macht.
Klar könnte jemand der das nicht weiß selbst recherchieren. Aber wenn man schon um nen Test bittet, dann ist das nicht gerade einladend.
 
Coo. Ich hab's mal auf meiner Büro-Box installiert und lasse es mitlaufen. Mal schauen was passiert.
 
Was mich ja ursprünglich zum Handeln bewegte war das ständige aufhäulen des Lüfters.
Erinnert mich an die Story, die ich mal aufschnappte, als ein Admin ein Stück Draht von außen in den Lüfter des Switches gekeilt vorfand und die Mitarbeiter sagten, dass das sein musste, weil zu laut. :D

Sag mal...wenn ich den portstree aktualisiere, dann geht das arg gemächlich zugange (habe noch die Vorgängerversion drauf), kein Unterschied bei adaptiv und high adaptiv. Mit dem standard-powerd rasen die Zeilen.
Ist das die normale gewünschte Auswirkung -also normal- oder mach ich was falsch?
 
120 Sekunden Aufnahme, gestartet während 'Applying patches...'

Lief wieder sehr langsam durch.
 

Anhänge

  • portsnap.txt.gz
    31,9 KB · Aufrufe: 242
Danke fuers update, aufn Thinkpad t480 (2018 model), gibt es folgendes problem:

Code:
miwitb# powerdxx -v
powerd++: cannot access sysctl: dev.cpu.1.freq
powerd++: cannot access sysctl: dev.cpu.2.freq
powerd++: cannot access sysctl: dev.cpu.3.freq
powerd++: cannot access sysctl: dev.cpu.4.freq
powerd++: cannot access sysctl: dev.cpu.5.freq
powerd++: cannot access sysctl: dev.cpu.6.freq
powerd++: cannot access sysctl: dev.cpu.7.freq
Terminal Output
        verbose:               yes
        foreground:            no
Load Sampling
        load samples:          4
        polling interval:      500 ms
        load average over:     2000 ms
Frequency Limits
        battery:               [0 MHz, 1000000 MHz]
        online:                [0 MHz, 1000000 MHz]
        unknown:               [0 MHz, 1000000 MHz]
CPU Cores
        CPU cores:             8
Core Groups
          0:                   [0, 7]
Core Frequency Limits
          0:                   [400 MHz, 2001 MHz]
Load Targets
        battery power target: 50% load
        online power target:  38% load
        unknown power target: 38% load
Temperature Throttling
        active:                yes
          0:                   [90 C, 100 C]

Module sind ordentlich geladen
Code:
6    1 0xffffffff82a4b000     2ba8 coretemp.ko
 7    1 0xffffffff82a4e000     7ce8 acpi_ibm.ko

Das alte powerd scheint ja soweit zu gehen. Irgendeine idee?
 
Danke fuers update, aufn Thinkpad t480 (2018 model), gibt es folgendes problem:

Code:
miwitb# powerdxx -v
...
Das alte powerd scheint ja soweit zu gehen. Irgendeine idee?
Was funktioniert den nicht?

Falls Du das "cannot access sysctl" meinst, das ist nur die Beschwerde, dass er die Kerne nicht individuell Takten kann.
 
120 Sekunden Aufnahme, gestartet während 'Applying patches...'

Lief wieder sehr langsam durch.
So wie das aussieht sind hier 2 Prozesse beteiligt, von denen der Eine auf den Input des anderen wartet. Dadurch verteilt sich die Last auf 2 Kerne, die dazu noch ständig wechseln, so dass die gemessene Last noch durch den Tiefpassfilter geschwächt wird.

Auf diesen Anwendungsfall ist der Original-powerd optimiert.

Es gäbe mehrere Möglichkeiten das auf powerd++ Seite anzugehen, leider erhöhen alle die Anfälligkeit für Rauschen.

Du könntest aber mal kern.sched.affinity erhöhen und schauen was passiert.
 
Auf diesen Anwendungsfall ist der Original-powerd optimiert.

Ich denke 1x entpacken und 1x auf Platte schreiben. :)

Ich hab mir das so schon gedacht. -> powerdxx soll ja eben nicht alle Kerne hochziehen/Turbo zünden, wenn die Last gering ist bzw. nur Last auf 2 Kernen.
Bei allen anderen Lasten läufts ja perfekt. ;)

Es gäbe mehrere Möglichkeiten das auf powerd++ Seite anzugehen, leider erhöhen alle die Anfälligkeit für Rauschen.
Mja, Henne-Ei.
 
Ich habe die neue Version nun zwei Arbeitstage benutzt und bisher habe ich nichts zu meckern. Gute Arbeit. :)
 
Du kannst die Last natürlich auch mit cpuset auf einen Core zwingen.

Jep, aber so unoft wie ich den portstree update, ist es wurscht, ob es 5 mins länger dauert. Coolness und Stromersparnis sind wichtiger.:)

Mich wunderte es nur anfangs, weil es markant auffiel und du bist ja dankbar, falls Bugs gefunden werden. Danke für das nette Tool auch von mir. :D
 
Hallo @Kamikaze

danke Dir, ich werde es später mal auf meinem Fujitsu E-Book ausprobieren und hier berichten.

Das Teil hat einen Quadcore und der Lüfter nervt schon so manches Mal ziemlich.
 
Also erstmal danke an Alle für das Feedback. Wenn bis zum Wochenende nichts neues kommt mache ich das Release.

@miwi Die verwirrende Ausgabe habe ich komplett weg gemacht.

@mr44er Für Dein Problem habe ich einen Ansatz aber der schafft es nicht in dieses Release.
 
Wegen meinereiner bloß keine Eile. :)

Ich gehe auch nicht davon aus, dass nur ich Betroffener bin, aufgrund Valencia-Reihe der Bulldozer-Architektur...das Problem müsste doch bei jedem so auftreten, oder? ;)
 
Ich fürchte, ich bin die nächsten 3-4 Wochen out of order und komme zu nix, weil größeres Projekt Realwelt. :(
 
Zurück
Oben