Freq Levels

h^2

hat ne Keule +1
Ich habe letzten im IRC shconmal berichtet, dass ich unter bestimmten loads, also eigentlich nur pkg installs, ein sehr, sehr träges System bekomme, obwohl die CPU-Auslastung nicht hoch, und auch keine hohe Interrupt-Rate. Yamagi meinte darauf hin, dass die CPU vlt auf falsche levels getaktet wird. Meine Sysctls sehen da so aus:
Code:
dev.cpu.0.freq: 800
dev.cpu.0.freq_levels: 3000/23530 2625/20588 2300/17400 2012/15225 1800/14520 1575/12705 1350/10890 1125/9075 900/7260 800/7315 700/6400 600/5486 500/4571 400/3657 300/2743 200/1828 100/914
dev.acpi_throttle.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
dev.hwpstate.0.freq_settings: 3000/23530 2300/17400 1800/14520 800/7315
Gehe ich in der Annahme richtig, dass die freq-settings des hwpstates die unterstützten levels sind und die unter freq_levels, die die powerd tatsächlich ansteuert? Dann wären ja wirklich einige dabei, die nicht gehen... Wenn ja, ist die sysctl schreibbar?
 
Von 3 GHz auf 800 Hz runter gedrosselt, ja das ist stark gedrosselt. Mein 3GHz Quadcore ließ sich auch auf sehr wenige Hz herunter drosseln, dann wurde das System aber auch etwas träge. Habe mir dann das FreeBSD Wiki Tuning Power Consumption durchgelesen und auf die ACPI Drossel durch editieren von /boot/loader.conf verzichtet:
Code:
hint.p4tcc.0.disabled=1
hint.acpi_throttle.0.disabled=1
Wie dort beschrieben:
https://wiki.freebsd.org/TuningPowerConsumption
 
Im Jahre 2009 hatte ich mal das Problem, habe mal die sysctl.conf aus einem Backup gepopelt:

Code:
debug.cpufreq.lowest=600

Ka obs immernoch so ist.
 
Jau. Wie ich im IRC schon sagte ist das Problem, dass es zwei Mechanismen für das Setzen von Powerstates gibt:
- Das Hersteller-Interface. Für AMD "hwpstate", für Intel "est". Wurde ab 2003 erst von AMD und später auch von Intel eingeführt, teilt dem System über spezielle Register die unterstützten Powerstates mit. Der Vorteil ist, dass die CPU selbst sagt, was sie unterstützt und wovon man besser die Finger lässt.
- Das ACPI Throttle Interface. Wurde eingeführt, um die Hersteller-Interfaces durch eine generische Lösung abzulösen. Die Powerstates stehen in der ACPI-Tabelle und werden per ACPI-Call gesetzt. In der Praxis ist ACPI Throtlle daher sinnlos, da viele Mainboardhersteller nicht unterstützte Frequenzen in BIOS programmieren. Wenn das Betriebssystem diese setzt, passieren seltsame Dinge. Miese Performance, die CPU schmiert ab und lässt sich nur doch "Strom weg" wiederbeleben und sowas.

In der Praxis schalten die meisten Linux-Distros ACPI Throttle aus. Windows scheint Quirk-Tables zu nutzen, d.h. nur aus ACPI oder das Hersteller-Interface zurückzufallen, wenn es die CPU nicht kennt. FreeBSD verschmilzt ACPI Throttle und das Hersteller-Interface zu einer gemeinsamen Tabelle. Meist hilft es bei Problemen ACPI Throttle abzuschalten. p4tcc auszuschalten, ist auf allem ab Core2 eine gute Idee. TCC war eine Erweiterung, die der CPU ermöglicht im Falle von Überhitzen eigenmächtig den Takt zu ändern. Der p4tcc-Treiber ermöglicht es, diese speziellen Powerstates ebenfalls per powerd zu setzen. Aber einerseits bringen weitere Powerstates kaum mehr was und andererseits haben moderne CPUs dank Power Gating seitens der Hardware bessere Möglichkeiten den Hitzetod zu verhindern. Und nicht zuletzt sei gesagt, dass moderne Intel-CPUs eh kaum mehr von Powerstates profitieren.
 
Zurück
Oben