hallo erstmal, ich habe das problem, dass ich zwar einen amd athlon X2 7750 prozi habe, der ja mit 2.7 pro kern läuft, mir jedoch in linux nur ein takt von 1.35ghz angezeigt wird. ich weiß, dass linux den prozi untertaktet wenn er nix zu tun hat, allerdings ändert sich das ganze auch bei über 90% auslastung nicht...
ich wollte das manuell ändern mittels folgender befehle: cpufreq-set -g userspace; cpufreq-set -d (untere grenze) 1.35GHz; cpufreq-set -u (obere grenze) 2.7GHz; cpufreq-set -f (der takt, den ich haben will, zB:) 2GHz;
mit cpufreq-info bekomme ich immer angezeigt, dass der takt noch bei 1.35GHz liegt. das gilt für alles, was ich bei cpufreq-set -f eingebe, außer natürlich bei werten über 2.7GHz, da ich im bios nicht übertaktet hatte. komischerweise habe ich beim codieren schon so etwa die leistung, die man mit 2.7GHz erwarten könnte, jedoch bleibt bei allen anzeigemöglichkeiten (cpufreq-info; systemmonitor; sysinfo im konqueror; die ausgabe 1.35GHz. auch die Vcore Voltage, die ich im systemmonitor nachschauen kann, entspricht nicht der, die ich in windows (hab zwei platten, auf einer is linux und die andre nutz ich für windows) oder direkt im bios nachschauen kann, nämlich ca 1.39V, sondern liegt bei 1.1V, was auch nur stimmen kann, wenn der takt wirklich bei 1.35 liegt, denn so stark untervolten lässt sich mein prozi bei echten 2.7 garantiert nicht.
ich habe eine möglichkeit gefunden, dennoch manuell etwas ändern zu können, nämlich indem ich vorher im bios auf 3GHz übertakte (funktioniert problemlos). dann kann ich nämlich mittels cpufreq-set -d -wertüber1.35GHz- den takt auf genau den -u, also den maximalwert, 3Ghz hochschrauben. ein einstellen durch cpufreq-set -f funktioniert nicht! ich kann also nur zwischen 1.35 und 3 GHz hin und her wechseln, undzwar in dem ich den -d wert, den minimalwert auf etwas höheres als 1.35 stelle, das ganze funktioniert auch nur solange ich im bios genau auf 3GHz übertaktet habe!
ich komme damit zwar ganz gut aus, aber etwas nervig ist es schon, zumal ich auch nicht höher als 3GHz komm, da er ja nur exakt 3GHz akzeptiert. in windows habe ich übrigens immer genau den von mir im bios eingestellten takt, von 1.6 (im bios komm ich nämlich gar nicht auf 1.35, also einen multiplikator von unter 8, herunter!!!) bis zu 3.4GHz, muss also irgendwie schon am system liegen.
ich würde mich freuen wenn jemand mir helfen könnte, ich bedank mich schonmal im vorraus :D
Archiv Prozessoren 8.660 Themen, 54.742 Beiträge
Mit den Details bei Suse kenne ich mich nicht so aus.
heißt das ich kann mir durch ändern der config datei mehr pstates ermöglichen?
Nein. Der Prozessor kann nur "Vollast" und "Halblast" und die Halblast mit der auf 1,1 V verminderten Kernspannung.
Wie funktioniert das ganze jetzt bei einem Zweikerner wie dem 7750 und einem Kernel der unter Linux, der auf Stromsparen und im Bedarfsfall "volle Pulle" eingestellt ist? Das funktioniert so bei mir ohne die cpufreq tools und mit den Kerneloptionen für den selbst kompilierten Kernel.
Jedenfalls habe ich das mit den möglichen Beobachtungstools so festgestellt
Nichts zu tun 1350 Hz
etwas zu tun ein Kern mit 1350 Hz ggf. 2. Kern dazunehmen auch mit 1350 Hz (die grafischen Systemmonitore zeigen dann schon mal 80 -bis 90% CPU Last an - stimmt ja auch bezogen auf 1350 Hz (Festplattenkopierereien, Archive entpacken etc.)
noch mehr zu tun Hochtakten auf 2700 Hz (Standardtakt) für den Prozessor - Effekt grafischer Monitor bei der Systemlast ist plötzlich bei etwas über 50 % - bezogen auf 2700 Hz. Für 1350 Hz wäre er bei vielleicht 120% was ja so nicht dargestellt wird.
Im normalen Desktopbetrieb und einer Grafikkarte mit aktivierter Hardwareunterstützung 3D (dann muss der Prozessor die 3D Effekte nicht übernehmen) taktet der Prozessor wirklich nur selten über 1350 Hz; es ist einfach kein Bedarf da.
Gut ist das bei Kompilierprozessen zu beobachten
Quellen herunterladen = Däumchendrehen
Quellen entpacken = 60-80 % mit 1350 Hz
Quellen kompilieren 80-100% mit 2700 Hz
Noch eine Anmerkung: die .config Datei ist die Steuerdatei zum kompilieren des Kernels für den dann gilt, welches Modul mit eingebaut wird oder weggelassen wird bzw. welches Modul mit welchen Optionen eingebaut wird. Wenn Du dort etwas ausprobieren willst und Optionen veränderst, muss für die Wirksamkeit der Kernel neu kompiliert werden. Im Allgemeinen sind bei den "fertigen" Distributionskerneln die Optionen so passend gesetzt, dass es für die Distribution und 99 % der Hardware und Betriebszustände keine Probleme gibt. (wird erreicht, dass fast alles eingeschaltet ist, egal ob benötigt oder nicht). Das ist für den Normalfall aber kein Nachteil. Eigenes Probieren kann dann schon mal dazu führen, dass das System nicht oder nicht komplett startet. Dafür richtet man sich im Bootmanager dann mehrere passende Einträge ein, wo einer für den sicher funktionierenden Kernel zuständig ist und weitere für den/die Experimentierkernel. Ich kann dann schauen, was passiert mit meinem Experiment und wenn es schief geht, starte ich den Rechner mit dem funktionierenden Kernel neu und experimentiere weiter.