Stromverbrauch im idle optimieren

h^2

hat ne Keule +1
Ich beschränke das Stromsparthema jetzt mal auf den idle-Betrieb, damit es nicht zu unübersichtlich wird.

Ich habe im Moment das System zusammengebaut, das ich auch schon hier beschrieben habe:

Also eine niedrig-stromige Intel CPU mit 4+4 Threads, 32GB RAM, 4 NVMEs und eine 10Gbit-Netzwerkkarte. Nach einiger Frickelei, habe ich das System im idle von 55W auf 41W runterbekommen.
Folgende Dinge haben dabei geholfen:

/boot/device.hints
Code:
# disable wifi, save energy
hint.iwlwifi.0.disabled="1"
# disable bluetooth, broken anyway
hint.ubt.0.disabled="1"

Danach tauchen die devices nicht mehr im dmesg auf. Allerdings noch in pciconf...
Die Onboard-Netzwerkkarte (2.5Gbit "Killer") kriegt per default keinen Treiber (aber es gibt einen in den Ports). Lade ich den Treiber geht der Verbrauch hoch, insofern scheint sie "korrekt abgeschaltet" zu sein ohne...? Es reduziert den idle-Verbrauch übrigens kaum die Onboard-Karte, statt der dedizierten zu nehmen.

/boot/loader.conf
Code:
# power saving
hw.pci.do_power_nodriver=3
machdep.hwpstate_pkg_ctrl=0

Letzteres spart tatsächlich Strom, auch wenn ich danach dev.hwpstate_intel.X.epp nicht anpasse. Wenn ich dev.hwpstate_intel.X.epp erhöhe, reduziere ich den Verbrauch unter Last, aber nicht im idle.

/etc/rc.conf
Code:
performance_cx_lowest="Cmax"
economy_cx_lowest="Cmax"

Die Kerne gehen auch brav in den S3:
Code:
% sysctl -a | fgrep -i cx_usage:
dev.cpu.7.cx_usage: 5.80% 18.84% 75.35% last 107752us
dev.cpu.6.cx_usage: 10.53% 22.46% 66.99% last 519us
dev.cpu.5.cx_usage: 9.68% 17.71% 72.59% last 10786us
dev.cpu.4.cx_usage: 5.65% 17.11% 77.22% last 8848us
dev.cpu.3.cx_usage: 5.33% 17.29% 77.36% last 1786us
dev.cpu.2.cx_usage: 13.78% 26.05% 60.16% last 214us
dev.cpu.1.cx_usage: 4.75% 21.90% 73.34% last 4329us
dev.cpu.0.cx_usage: 4.85% 15.11% 80.03% last 38us

Ich habe mit den Power-Saving modi der NVME gespielt (nvmecontrol) und das beeinflusst den Verbrauch unter Last deutlich, aber macht im idle 0 Unterschied.

Folgende Ressourcen habe ich gelesen, scheinen aber sehr out-of-date:

Fällt euch sonst noch was ein? Sind 41W für so ein System "normal"? Ich hatte eigentlich schon gehofft auf ca. 30W runter zu kommen.

Habe mit etwas Neid das hier gelesen:
17W im idle sind natürlich schon eine andere Hausnummer...
 
/boot/device.hints
Code:
# disable wifi, save energy
hint.iwlwifi.0.disabled="1"
# disable bluetooth, broken anyway
hint.ubt.0.disabled="1"
Danach tauchen die devices nicht mehr im dmesg auf. Allerdings noch in pciconf...
Deaktiviere alles im BIOS, dann kannst du dir das mit device.hints sparen.
Ebenfalls serial/parallel-port deaktiveren sowie die Soundkarte.
Lade ich den Treiber geht der Verbrauch hoch, insofern scheint sie "korrekt abgeschaltet" zu sein ohne...?
Das sollte andersrum sein. Aber wenn du sie nicht nutzt, schalte auch diese im BIOS ab.

Ich würde auch anders an die Sache rangehen und zwar das Board so nackt wie möglich booten und mit allem verzichtbaren Krempel im BIOS deaktiviert. Dann ein Minütchen warten und auf den Verbrauch schauen, damit du einen Basiswert hast.
Jetzt eine Komponente einbauen (weitere NVMe oder die 10G NIC), erneut booten und schauen. Somit bekommst du einen Überblick, was ggf. die einzelnen Mehrkomponenten so wegnuckeln, ob sie korrekt idle gehen, ob man Treiber/Settings wechseln muss oder ob sie niedrige states irgendwo zunichte machen.

Sind 41W für so ein System "normal"?
Ja und wie im anderen Thread erwähnt wärst du mit der dicksten CPU für den Sockel im idle höchstwahrscheinlich auch in diesem Bereich, vielleicht bei höhrer Kernzahl dann bei 43-44W.

Je nach GPU und Unterstützung im Treiber kann es einen Unterschied machen, ob man den Bildschirm abstöpselt. HDMI bedeutet auch nochmal 'Soundkarte', aber auch bei allen anderen kann es was nützen.
 
Deaktiviere alles im BIOS, dann kannst du dir das mit device.hints sparen.
Ebenfalls serial/parallel-port deaktiveren sowie die Soundkarte.
Im BIOS kann man keine der Komponenten deaktivieren, das hatte ich natürlich als erstes versucht. Aber GARNICHTS lässt sich deaktivieren, es ist ein Trauerspiel. Selbst im "Expertenmodus" nicht ;'(
Ich würde auch anders an die Sache rangehen und zwar das Board so nackt wie möglich booten und mit allem verzichtbaren Krempel im BIOS deaktiviert. Dann ein Minütchen warten und auf den Verbrauch schauen, damit du einen Basiswert hast.
Ohne NIC braucht es 1-2W weniger, wenn ich mich richtig erinnere. Ohne die NVMEs müsste ich es von einem USB-Stick booten. Das könnte ich nochmal machen. Andererseits werde ich die NVMEs nach dem ganzen Gebenchmarke und so jetzt auch nicht mehr zurückschicken.
Je nach GPU und Unterstützung im Treiber kann es einen Unterschied machen, ob man den Bildschirm abstöpselt. HDMI bedeutet auch nochmal 'Soundkarte', aber auch bei allen anderen kann es was nützen.
Im Normalbetrieb ist natürlich sonst nichts angeschlossen. Die Soundkarte(n) dürften unter FreeBSD ja auch nichts ziehen, denn standardmäßig sind doch keine Treiber geladen und ich habe hw.pci.do_power_nodriver=3...?
 
Gerade im Idle hat den größten Stromverbrauch schlicht das Mainboard + Arbeitsspeicher und da kann man auch kaum was gegen machen. Würde mich nicht wundern, wenn deine 32GB RAM schon so ~10W brauchen. 4 NVMe laufen auch nicht gänzlich ohne Strom. Es läppert sich.

Darum sind die ~40W schon ganz gut. Der ganze Kram ist halt nicht auf Stromverbrauch optimiert. Darum haben Notebooks ja in der Regel auch keine Desktop-Komponenten.

Zum Vergleich: Mein ASUS ROG Ally Handheld mit WLAN, Bluetooth, Bildschirm, NVMe, 16GB RAM und eben der 8 Kerne / 16 Threads CPU braucht ~6W im Idle.
 
es ist ein Trauerspiel. Selbst im "Expertenmodus" nicht
Das ist natürlich schade. :(

Das könnte ich nochmal machen. Andererseits werde ich die NVMEs nach dem ganzen Gebenchmarke und so jetzt auch nicht mehr zurückschicken.
Ich wollte darauf hinaus, dass du mit dem nacktmöglichsten Boot einen Basiswert hast, es sich dann je Komponente realistisch und plausibel addiert. Wenn du jetzt eine NVMe zusteckst und 120W im idle brutzelst, weißt du dann, dass was definitiv nicht stimmt...als krasses Gegenbeispiel. ;)

standardmäßig sind doch keine Treiber geladen und ich habe hw.pci.do_power_nodriver=3...?
Eher dann, wenn keine Treiber geladen sind, läufts bis auf Ausnahmen auf Vollgas. Prüfe mal deinen Verbrauch, während du dich im BIOS befindest.
Es reicht ja eine einzige Komponente, die einen guten Verbrauch kaputt macht.

Die 40W sind insgesamt realistisch, aber das muss nicht heißen, dass nicht doch noch was geht (GPU Treiber hust) . Deswegen ja mein Stupser zum Basiswert. ;)

Edit:
Anderer Ansatz, besorge dir mal eine Win10 oder 11 .iso und installiere das mit UEFI, du brauchst auch keinen Key, da gehts um nen schnellen Test.
Einfach normal Windows aufbügeln, alle Treiber installieren und dann gucken, ob du einen anderen Basiswert bekommst. Es dürfte der geringste sein. Wenn du mit FreeBSD gleichauf oder ~4-5W drüber bist, ist das realistisch und korrekt.
 
Fällt euch sonst noch was ein? Sind 41W für so ein System "normal"? Ich hatte eigentlich schon gehofft auf ca. 30W runter zu kommen.
Was hast du für ein Netzteil drin (wieviel Watt)?
Netzteile haben einen besseren Wirkungsgrad, wenn sie z.B. bei 80% der Nennleistung betrieben werden als an nur 20%, d.h der Eigenverbrauch schwankt dementsprechend; bei um die 40W kanns schon auch noch 10-12 % dessen ausmachen.

EDIT: hab grad gesehen du hast ein 300W drin - da sind 40W grad mal 13% der Nennleistung, da könnten durchaus noch 4 - 5W von den 41W allein dieser Tatsache geschuldet sein.

EDIT2: rein schätzomativ (ohne jetzt groß Datenblätter gesichtet zu haben) würd ich sagen, dass allein deine 4 nvmes und die 10gig Karte zusammen schon ca 22 W brauchen, rechnet man dann noch was fürs Mainboard selber (samt RAM) und der idle-CPU mit den 4C mit ein, dann könnten die 41W durchaus plausibel sein; manche Boards haben auch nen höheren Eigenverbrauch (ohne CPU und RAM, nur Boardkomponenten) als andere;
 
Im BIOS kann man keine der Komponenten deaktivieren, das hatte ich natürlich als erstes versucht.
Ich hatte vergessen, dass man Soundkarte ausschalten kann, war aber schon von mir. Ebenfalls ausgeschaltet die Onboard-NIC (macht aber keinen Unterschied zu ohne-Treiber), und außerdem der komplette SATA-Controller.
Was ich wirklich gerne ausschalten würde, was aber nicht geht: WLAN+Bluetooth.
Darum sind die ~40W schon ganz gut. Der ganze Kram ist halt nicht auf Stromverbrauch optimiert. Darum haben Notebooks ja in der Regel auch keine Desktop-Komponenten.
Wenn ich nicht die vielen NVMEs verbauen wollte, hätte ich mir mir das letzte Framework-Mainboard geholt!
Eher dann, wenn keine Treiber geladen sind, läufts bis auf Ausnahmen auf Vollgas. Prüfe mal deinen Verbrauch, während du dich im BIOS befindest.
Hm, echt? Da habe ich anderes gehört. Im BIOS ist der Verbrauch übrigens deutlich höher als in FreeBSD.
Die 40W sind insgesamt realistisch, aber das muss nicht heißen, dass nicht doch noch was geht (GPU Treiber hust) . Deswegen ja mein Stupser zum Basiswert.
Zu GPU habe ich bis jetzt gar nichts gelesen. Was sind da meine Optionen?
hab grad gesehen du hast ein 300W drin - da sind 40W grad mal 13% der Nennleistung, da könnten durchaus noch 4 - 5W von den 41W allein dieser Tatsache geschuldet sein.
Ich hätte gerne eine niedriger-wattiges genommen, aber sowas scheint es nicht mehr auf dem Markt zu geben...

ABER ich habe noch was wirklich wichtiges gefunden: der Heise-Artikel hat einen Hinweis auf "PCIe ASPM Mode", das sind die Einstellungen, die Stromsparen der PCIe Devices regeln. Davon gibt es in meinem BIOS vier unterschiedliche Knöpfe mit zum Teil mehreren Einstellmöglichkeiten, die alle per Default auf "Disabled" waren. Nachdem ich die auf Enabled bzw. L0s+L1 und L1 gesetzt habe geht der IDLE-Verbrauch von 42W auf 33W runter!

Mega. Was sich da so alles verbirgt im BIOS. Da sind noch sehr viele Optionen, die ich überhaupt nicht kenne, das muss ich mir nochmal angucken.
 
Hm, echt? Da habe ich anderes gehört. Im BIOS ist der Verbrauch übrigens deutlich höher als in FreeBSD.
Das bestätigt doch meine Aussage :)

Zu GPU habe ich bis jetzt gar nichts gelesen. Was sind da meine Optionen?
Einfach den passenden Treiber laden wenn nicht schon geschehen, damit auch Stromsparfunktionen dafür greifen. In der manpage des Treibers gucken, ob es da noch ein paar knobs gibt, die man setzen könnte. War das jetzt ein Serverboard? Wenn das nur ein aspeed oä. ist, geht dann nicht mehr viel. Bei Intel, AMD und nvidia gibts ggf. noch das ein oder andere...man muss es immer durchtesten, ob das dann bei abgezogenem Monitor die GPU abschaltet bzw. in einen tieferen state geht, aber der passende Treiber dürfte die Grundvoraussetzung sein.

auf "PCIe ASPM Mode", das sind die Einstellungen, die Stromsparen der PCIe Devices regeln. Davon gibt es in meinem BIOS vier unterschiedliche Knöpfe mit zum Teil mehreren Einstellmöglichkeiten, die alle per Default auf "Disabled" waren. Nachdem ich die auf Enabled bzw. L0s+L1 und L1 gesetzt habe geht der IDLE-Verbrauch von 42W auf 33W runter!
Ja, ich hätte erwartet, dass zumindest L0 default enabled ist. Sollten timeouts oder andere komische Dinge beim Netzwerk passieren, teste zunächst nur mit L0...
 
Bei Deinem Verbrauch könnte eine PicoPSU, bzw. MiniiPSU interessant sein. Die bringen in dem Bereich gerne noch einmal 5W. Du musst halt Deinen Maximalverbrauch abschätzen. Die PicoPSU habe ich schon mit 160 W gesehen. PicoPSU 160
 
Einfach den passenden Treiber laden wenn nicht schon geschehen, damit auch Stromsparfunktionen dafür greifen.
Das war schonmal nicht erfolgreich:
Code:
Feb  8 21:00:12 revres kernel: drmn0: successfully loaded firmware image 'i915/adls_dmc_ver2_01.bin'
Feb  8 21:00:12 revres kernel: drmn0: [drm] Finished loading DMC firmware i915/adls_dmc_ver2_01.bin (v2.1)
[...]
Feb  8 21:00:13 revres kernel: PPS state mismatch
Feb  8 21:00:14 revres kernel: drmn drmn0: eDP powered off while attempting aux channel communication.
Feb  8 21:00:14 revres kernel: drmn drmn0: drm_WARN_ON(intel_dp->pps.vdd_wakeref)
[...]
Feb  8 21:00:20 revres kernel: drmn drmn0: eDP powered off while attempting aux channel communication.
Feb  8 21:00:20 revres kernel: drmn0: [drm] failed to retrieve link info, disabling eDP
Feb  8 21:00:20 revres kernel: drmn drmn0: drm_WARN_ON(!intel_gmbus_is_valid_pin(dev_priv, pin))drmn drmn0: drm_WARN_ON(!intel_gmbus_is_valid_pin(dev_priv, pin))
Feb  8 21:00:20 revres kernel: drmn0: [drm] [ENCODER:235:DDI TC1/PHY B] is disabled/in DSI mode with an ungated DDI clock, gate it
Feb  8 21:00:20 revres kernel: drmn0: successfully loaded firmware image 'i915/tgl_guc_62.0.0.bin'
Und dann hing das System und der Stromverbrauch ging schlagartig um 12W hoch.
Bei Deinem Verbrauch könnte eine PicoPSU, bzw. MiniiPSU interessant sein. Die bringen in dem Bereich gerne noch einmal 5W. Du musst halt Deinen Maximalverbrauch abschätzen. Die PicoPSU habe ich schon mit 160 W gesehen. PicoPSU 160
Ich habe noch eine PicoPSU 60W in der Firewall, und war immer zufrieden. Aber hatte von der 160W Version keine mit Netzteil gefunden — jetzt gibt es sie auch nur bei einem Händler, der ne 1.5⭐ Bewertung hat.
Ich war mir auch unsicher, ob die den Dauerbetriebt aushält. Aber wäre vielleicht einen Versuch wert gewesen....
 
Das war schonmal nicht erfolgreich:
Das würde ich nochmal mit L0-only (zu tiefe states können, aber müssen keine Probleme verursachen) oder deaktiviert versuchen, einfach um zu wissen, ob es daran lag. Ebenfalls ist immer ein guter Tip, drm-kmod aus den ports zu bauen.
 
Das würde ich nochmal mit L0-only (zu tiefe states können, aber müssen keine Probleme verursachen) oder deaktiviert versuchen, einfach um zu wissen, ob es daran lag.
Habs probiert, gleiches Ergebnis. Wenn ich allerdings den Treiber in die loader.conf eintrage, dann kommt das System trotzdem hoch und er taucht später in der kldstat auf. Aber nicht in der dmesg, also "attacht" der Treiber dann aus irgendeinem Grund nicht richtig, denke ich. Hat sich auf jeden Fall nicht auf dem Stromverbrauch ausgewirkt. Das versuch ich irgendwann in der Zukunft vielleicht noch mal; der Chipsatz ist halt noch super-neu.

Es gibt allerdings ein Beta-Bios mit dem man jetzt auch WLAN+BT ausgeschaltet kriegt. Das hat nochmal ein gutes Watt eingespart. Ich werde am Sonntag nochmal versuchen Intel Speedshift auszuschalten, und gucken ob der powerdxx das System weiter runterkriegt, aber überall heißt es dass Speedshift eigentlich sparsamer ist als manuelle Kontrolle.
 
Wenn ich allerdings den Treiber in die loader.conf eintrage, dann kommt das System trotzdem hoch und er taucht später in der kldstat auf.
Das sollte in die rc.conf https://docs.freebsd.org/en/books/handbook/x11/#x-configuration-intel
Ob das bei der jetzigen Version einen Unterschied macht, weiß ich nicht. Nvidia hier, aber auch da lade ich über die rc.conf.
Das versuch ich irgendwann in der Zukunft vielleicht noch mal; der Chipsatz ist halt noch super-neu.
Auch möglich, dass es daran liegt.

Es gibt allerdings ein Beta-Bios mit dem man jetzt auch WLAN+BT ausgeschaltet kriegt. Das hat nochmal ein gutes Watt eingespart.
Nice! :)

aber überall heißt es dass Speedshift eigentlich sparsamer ist als manuelle Kontrolle.
Ja. Ich meine auch, dass das hier schon gut technisch begründet wurde, sollte sich via Suchfunktion finden lassen. Weil AMD-Fanboy, habe ich hier kein neues Intel-System und somit keinerlei Erfahrung. Aber Versuch mach kluch :)
 
erreicht man die von Matt beschriebenen States C8 und C10 auch mit FreeBSD?
bin irgendwie noch auf dem Stand "tiefster State ist C3"
 
FreeBSD hing da immer ein paar Watt hinter Linux, aber warum kann ich gar nicht sagen und auch nicht, ob das immer noch so ist.

Gibts denn was Vergleichbares wie powertop und für AMD, wo ich das auslesen könnte?
 
turbostat kann dir den Verbrauch des CPU-Package anzeigen. Je nach CPU-Modell mit oder ohne DRAM.
 
Bei mir kommt da eine Floating point exception. :zitter:
Code:
turbostat version 17.06.23 - Len Brown <lenb@kernel.org>
CPUID(0): GenuineIntel 32 CPUID levels; family:model:stepping 0x6:be:0 (6:190:0)
CPUID(1): SSE3 MONITOR - EIST TM2 TSC MSR ACPI-TM TM
CPUID(6): APERF, TURBO, DTS, PTM, HWP, HWPnotify, HWPwindow, HWPepp, HWPpkg, EPB
cpu2: MSR_IA32_MISC_ENABLE: 0x00850089 (TCC EIST No-MWAIT PREFETCH TURBO)
CPUID(7): No-SGX
CPUID(0x15): eax_crystal: 2 ebx_tsc: 42 ecx_crystal_hz: 38400000
TSC: 806 MHz (38400000 Hz * 42 / 2 / 1000000)
CPUID(0x16): base_mhz: 800 max_mhz: 3400 bus_mhz: 100
NSFOD /sys/devices/system/cpu/cpu2/cpufreq/scaling_driver
Floating point exception (core dumped)
 
dito, bei mir auch, floating point exception, egal ob als root oder mittels doas ausgeführt;
truss sagt noch SIGNAL 8 (SIGFPE), FPE_INTDIV trapno=18
 
Okay, hier funktioniert es unter FreeBSD auch nicht. Da ist der Port wohl kaputt. Wenn es ginge, könnte man sowas machen:

Code:
root@killua:pts/17 + ~> turbostat --show PkgWatt,CorWatt
turbostat version 2024.05.10 - Len Brown <lenb@kernel.org>
Kernel command line: initrd=\initramfs-linux.img mitigations=off cryptdevice=PARTLABEL=sys:sys:allow-discards resume=/dev/mapper/sys-swap root=/dev/mapper/sys-root rootflags=discard rw quiet
CPUID(0): AuthenticAMD 0x10 CPUID levels
CPUID(1): family:model:stepping 0x17:71:0 (23:113:0) microcode 0x0
CPUID(0x80000000): max_extended_levels: 0x80000020
CPUID(1): SSE3 MONITOR - - - TSC MSR - HT -
CPUID(6): APERF, No-TURBO, No-DTS, No-PTM, No-HWP, No-HWPnotify, No-HWPwindow, No-HWPepp, No-HWPpkg, No-EPB
CPUID(7): No-SGX No-Hybrid
cpu0: cpufreq driver: acpi-cpufreq
cpu0: cpufreq governor: schedutil
cpufreq boost: 1
/dev/cpu_dma_latency: 2000000000 usec (default)
current_driver: acpi_idle
current_governor: menu
current_governor_ro: menu
cpu0: POLL: CPUIDLE CORE POLL IDLE
cpu0: C1: ACPI FFH MWAIT 0x0
cpu0: C2: ACPI IOPORT 0x414
RAPL: 234 sec. Joule Counter Range, at 280 Watts
cpu0: MSR_RAPL_PWR_UNIT: 0x000a1003 (0.125000 Watts, 0.000015 Joules, 0.000977 sec.)
CorWatt PkgWatt
4.33    19.34
0.69    19.34
0.35
0.29
0.21
0.58
0.66
0.83
0.72

Das ist ein Ryzen 3700X, also ein Zen 2. Hier sieht man auch gleich gut das Problem der großen Ryzen-CPUs, da es eine verkappte eine Serverplattfom ist, braucht das für Desktops völlig überzüchtete I/O-Die einfach unendlich viel Strom, was den Idle-Verbrauch massiv hochtreibt. Wenn man das mit einem der großen Chipsätze kombiniert - bei AM5 ist der X670 ein weiteres I/O-Die, X670E sind sogar zwei davon - wird es unschön. Die monolithischen CPUs, also auch @mr44er mit dem 8600G, sind als Notebookplattform wesentlich stromsparender, idealerweise nimmt man dazu mit dem A620 den kleinsten Chipsatz. Der ist allerdings in seinen Möglichkeiten recht begrenzt, daher kommt er vielleicht gar nicht in Frage.

Mein System hat einen älteren B450 Chipsatz und eine Radeon 5700X. Die Radeon zieht noch mal 10W:

Code:
amdgpu-pci-0900
Adapter: PCI adapter
vddgfx:      750.00 mV
fan1:           0 RPM  (min =    0 RPM, max = 3200 RPM)
edge:         +43.0°C  (crit = +100.0°C, hyst = -273.1°C)
                       (emerg = +105.0°C)
junction:     +43.0°C  (crit = +107.0°C, hyst = -273.1°C)
                       (emerg = +112.0°C)
mem:          +44.0°C  (crit = +105.0°C, hyst = -273.1°C)
                       (emerg = +110.0°C)
PPT:          10.00 W  (cap = 195.00 W)

Mein Energiemessgerät sagt, dass 36W aus der Steckdose gezogen werden. Also bleiben 36W-10W-19W=7W für alles außer CPU und Grafikkarte.
 
Okay, hier funktioniert es unter FreeBSD auch nicht. Da ist der Port wohl kaputt.


wird ggf auch vielleicht so schnell nichts mit ner Reparatur... :(

===> NOTICE:

The turbostat port currently does not have a maintainer. As a result, it is
more likely to have unresolved issues


sowas wie powertop [--auto-tune] unter Linux gibts für *BSD leider nicht, oder? Mir wär zumindest nichts bekannt;
 
Bei mir läuft es tatsächlich ohne zu crashen (ist ja ne Intel-CPU), aber liefert leider keine Watt-Angaben:
Code:
turbostat version 17.06.23 - Len Brown <lenb@kernel.org>
CPUID(0): GenuineIntel 32 CPUID levels; family:model:stepping 0x6:97:5 (6:151:5)
CPUID(1): SSE3 MONITOR - EIST TM2 TSC MSR ACPI-TM TM
CPUID(6): APERF, TURBO, DTS, PTM, HWP, HWPnotify, HWPwindow, HWPepp, HWPpkg, EPB
cpu2: MSR_IA32_MISC_ENABLE: 0x00850089 (TCC EIST No-MWAIT PREFETCH TURBO)
CPUID(7): No-SGX
CPUID(0x15): eax_crystal: 2 ebx_tsc: 114 ecx_crystal_hz: 38400000
TSC: 2188 MHz (38400000 Hz * 114 / 2 / 1000000)
CPUID(0x16): base_mhz: 2200 max_mhz: 4100 bus_mhz: 100
NSFOD /sys/devices/system/cpu/cpu2/cpufreq/scaling_driver
cpu0: MSR_PM_ENABLE: 0x00000001 (HWP)
cpu0: MSR_HWP_CAPABILITIES: 0x010c1c35 (high 53 guar 28 eff 12 low 1)
cpu0: MSR_HWP_REQUEST: 0x80003501 (min 1 max 53 des 0 epp 0x80 window 0x0 pkg 0x0)
cpu0: MSR_HWP_REQUEST_PKG: 0x8000ff01 (min 1 max 255 des 0 epp 0x80 window 0x0)
cpu0: MSR_HWP_INTERRUPT: 0x00000000 (Dis_Guaranteed_Perf_Change, Dis_Excursion_Min)
cpu0: MSR_HWP_STATUS: 0x00000000 (No-Guaranteed_Perf_Change, No-Excursion_Min)
cpu0: MSR_IA32_ENERGY_PERF_BIAS: 0x00000000 (performance)
cpu0: Guessing tjMax 100 C, Please use -T to specify
cpu0: MSR_IA32_PACKAGE_THERM_STATUS: 0x883f0000 (37 C)
cpu0: MSR_IA32_PACKAGE_THERM_INTERRUPT: 0x00000000 (100 C, 100 C)
Core    CPU     Avg_MHz Busy%   Bzy_MHz TSC_MHz IRQ     CoreTmp PkgTmp
-       -       2       0.25    796     2189    465     36      38
0       0       2       0.25    796     2189    76      34      38
0       1       2       0.29    796     2189    48
1       2       1       0.18    796     2189    33      36
1       3       2       0.19    796     2189    35
2       4       2       0.29    796     2189    40      34
2       5       1       0.14    796     2189    32
3       6       4       0.51    796     2189    154     35
3       7       1       0.16    796     2189    47

Ich habe da auch noch das intel-pcm Paket gefunden. Das liefert auch allerlei Daten:
Code:
 UTIL  : utlization (same as core C0 state active state residency, the value is in 0..1)  
 IPC   : instructions per CPU cycle
 CFREQ : core frequency in Ghz
 L3MISS: L3 (read) cache misses  
 L2MISS: L2 (read) cache misses (including other core's L2 cache *hits*)  
 L3HIT : L3 (read) cache hit ratio (0.00-1.00)
 L2HIT : L2 cache hit ratio (0.00-1.00)
 L3MPI : number of L3 (read) cache misses per instruction
 L2MPI : number of L2 (read) cache misses per instruction
 READ  : bytes read from main memory controller (in GBytes)
 WRITE : bytes written to main memory controller (in GBytes)
 TEMP  : Temperature reading in 1 degree Celsius relative to the TjMax temperature (thermal headroom): 0 corresponds to the max temperature
 energy: Energy in Joules


 Core (SKT) | UTIL | IPC  | CFREQ | L3MISS | L2MISS | L3HIT | L2HIT | L3MPI | L2MPI |  TEMP

   0    0     0.00   0.77    0.80      40 K   2144      0.20    0.37  0.0243  0.0013     63
   1    0     0.00   0.23    0.80      16 K   1825      0.60    0.29  0.0575  0.0065     63
   2    0     0.00   0.20    0.80      39 K   2490      0.36    0.36  0.0996  0.0063     65
   3    0     0.00   0.17    0.80    6389      499      0.51    0.37  0.0811  0.0063     65
   4    0     0.00   0.15    0.80      13 K   1903      0.72    0.33  0.0554  0.0077     65
   5    0     0.00   0.54    0.80      11 K    758      0.26    0.71  0.0211  0.0013     65
   6    0     0.00   0.12    0.80      23 K   1568      0.46    0.36  0.1010  0.0068     64
   7    0     0.00   0.13    0.80      10 K    760      0.48    0.39  0.0923  0.0064     64
---------------------------------------------------------------------------------------------------------------
 SKT    0     0.00   0.32    0.80     162 K     11 K    0.45    0.40  0.0452  0.0033     61
---------------------------------------------------------------------------------------------------------------
 TOTAL  *     0.00   0.32    0.80     162 K     11 K    0.45    0.40  0.0452  0.0033     N/A

 Instructions retired: 3583 K ; Active cycles:   11 M ; Time (TSC): 2219 Mticks ; C0 (active,non-halted) core residency: 0.17 %

 C1 core residency: 3.08 %; C3 core residency: 0.00 %; C6 core residency: 0.00 %; C7 core residency: 96.74 %;
 C0 package residency: 100.00 %; C2 package residency: 0.00 %; C4 package residency: 0.00 %; C6 package residency: 0.00 %;
                             ┌───────────────────────────────────────────────────────────────────────────────┐
 Core    C-state distribution│1177777777777777777777777777777777777777777777777777777777777777777777777777777│
                             └───────────────────────────────────────────────────────────────────────────────┘
                             ┌────────────────────────────────────────────────────────────────────────────────┐
 Package C-state distribution│00000000000000000000000000000000000000000000000000000000000000000000000000000000│
                             └────────────────────────────────────────────────────────────────────────────────┘
 Pipeline stalls: Frontend bound: 31 %, bad Speculation: 4 %, Backend bound: 56 %, Retiring: 7 %
                             ┌────────────────────────────────────────────────────────────────────────────────┐
 Pipeline stall distribution │FFFFFFFFFFFFFFFFFFFFFFFFFSSSSBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBRRRRRR│
                             └────────────────────────────────────────────────────────────────────────────────┘

---------------------------------------------------------------------------------------------------------------

MEM (GB)->|  READ |  WRITE | CPU energy | PP0 energy | PP1 energy |
---------------------------------------------------------------------------------------------------------------
 SKT   0     0.03     0.00       1.36       0.09       0.00
---------------------------------------------------------------------------------------------------------------

Aber auch nichts aufschlussreiches zu den Watt. pcm-power sagt Unspported processor model.

Interessant ist aber, dass pcm behauptet die Cores würden in C7 gehen. sysctl behauptet das sei nicht supported:
Code:
# sysctl dev.cpu.0.
dev.cpu.0.temperature: 37.0C
dev.cpu.0.coretemp.throttle_log: 0
dev.cpu.0.coretemp.tjmax: 100.0C
dev.cpu.0.coretemp.resolution: 1
dev.cpu.0.coretemp.delta: 63
dev.cpu.0.cx_method: C1/mwait/hwc C2/mwait/hwc C3/mwait/hwc
dev.cpu.0.cx_usage_counters: 7136967 24822337 163715322
dev.cpu.0.cx_usage: 3.64% 12.68% 83.66% last 8786us
dev.cpu.0.cx_lowest: C8
dev.cpu.0.cx_supported: C1/1/1 C2/2/127 C3/3/1048
dev.cpu.0.freq_levels: 2188/-1
dev.cpu.0.freq: 794
dev.cpu.0.%parent: acpi0
dev.cpu.0.%pnpinfo: _HID=ACPI0007 _UID=0 _CID=none
dev.cpu.0.%location: handle=\_SB_.PR00
dev.cpu.0.%driver: cpu
dev.cpu.0.%desc: ACPI CPU
 
sysctl behauptet das sei nicht supported:
Das muss nicht stimmen, gerade auch wenn C8 noch dabei steht: dev.cpu.0.cx_lowest: C8
Ich weiß nicht, wieviel davon korrekt mit den neuen Architekturen noch erfasst werden kann. Im Zweifel ist das Messgerät zuverlässiger und ob die gesteckten Karten zu ASPM mitspielen, sofern das aktiv ist. Da kann man normalerweise auch zwei Modi wählen (ACPI controlled und BIOS controlled) und wenn man noch L0+L1 wählen kann, dann bestenfalls sorum.
 
Zurück
Oben