Suchergebnisse
Suchergebnisse 1-16 von insgesamt 16.
-
Paar Sachen zu PM generell, die du im IOReg überprüfen kannst:Lädt das X86PlatformPlugin mit definierten CPUPStates im IORegExplorer? Lädt der AppleHPET für das Device HPET? Lädt der AppleLPC für das Device LPCB? Lädt AppleACPICPU für jeden CPU Core? Lädt AGPM für Grafik? Zudem: Hast du dich mal mit XCPM befasst? Geben diese beiden Terminal Befehle jeweils 1 aus?sysctl -n machdep.xcpm.modesysctl -n machdep.xcpm.vectors_loaded_count
-
Ich glaube eher nicht, dass das bei deinem Intel i5-2520M mit XCPM was wird...
-
Joa, der PluginType sorgt dafür, dass das oben erwähnte X86PlatformPlugin geladen wird. Die CPU taktet dann mit den für das gewählte SMBios verfügbaren CPU-States.(Zitat von armut)Ja, und so ist es auch. Ich selber benutze eigentlich auch nur eine SSDT zum setzen des PluginType, aber auch nur eigentlich, denn ich übertakte meine CPU und diese nimmt den neuen Takt nur an, wenn CPU States für diesen Takt (zB 4,8 GHz) verfügbar sind. Deswegen sind in der SSDT zusätzlich weitere CPU States definiert…
-
(Zitat von Harper Lewis)Naja, das X86PlatformPlugin lädt jetzt einfach nicht... Wie sieht denn das Energie Sparen Menü in den SysEinstellungen jetzt bei dir aus?
-
Sieht das (Bild unten) aus wie MacBook? Also ich finde es ist eher andersherum, denn wieso sollte ein MacBook die Option zum automatischen Starten nach Stromausfall haben...Mit dem X86PlatformPlugin kommen noch einige Dependencies mehr, als nur CPUStates. Soweit ich weiß ist das X86PlatformPlugin auch nötig für korrekt funktionierendes HWP (vorausgesetzt die Hardware kann dies) und der Treiber wird für jeden aktuellen iMac geladen. Ich weiß nicht wie sinnvoll es ist einfach den Treiber komplett …
-
(Zitat von Harper Lewis)Und das X86PlatformPlugin wird geladen? Das wäre dann optimal...
-
Weniger SpeedSteps --> weniger SpeedStep-Switching --> schnellere Anpassung auf plötzlichen CPU Load --> schnellere Reaktion...Sehr viele Speedsteps zu haben muss nicht immer ein Vorteil sein. Bei Laptops ist das natürlich eine andere Sache
-
Ja, du hast da schon nicht unrecht, wirklich merken wird man da keinen großen Unterschied, das ist alles rein theoretisch.An Stromverbrauch wird sich da aber bei einem Desktop PC auch nicht grenzenlos was ändern wenn es ein paar Speedsteps mehr gibt. Bei einem Laptop ist das schon eher merkbar, denn hier ist fast schon jede Minute mehr oder weniger merkbar.Wer nicht mit den Taktraten zufrieden ist, dem würde ich derzeit raten die FrequencyVectors im X86PlatformPlugin zu verändern. Es gibt da ein…
-
Ich greife das Thema wegen dem hier nochmal auf:(Zitat von kuckkuck)(Zitat von rubenszy)Wer sich den Thread mal durchliest, versteht schnell, warum die Benutzung von CPUFriend ohne Veränderung der benutzten Plist aus dem X86PlatformPlugin keinen Sinn macht.Deswegen hier meine Frage, hat jemand schonmal folgendes versucht? freqVectorsEdit.sh von Pike ausführen und die Board ID eines Macs wählen, der am nähesten zur eigenen CPU passt (bei mir zb Mac-FA842E06C61E91C5, der den i7 4790k besitzt) Wich…
-
Also hast dus so gemacht wie von mir beschrieben, mit der Kombi aus freqVectorsEdit und CPUFriend? Lädt das X86PlatformPlugin?Du kannst wie verlinkt im X86Plugin den LFM noch weiter runter setzen (500 MHz), wenn deine CPU das unterstützt... Vielleicht funktionierts
-
Bei 02 00 00 00 0D 00 00 00 01 00 00 00 00 00 00 00 ist ja das Limit noch drinnen.Mal mit eingetragenen 500 als LFM probiert?
-
Sauber! Genau so war das gedacht! Vielleicht kann ja noch jemand das ganze testen und wenn es gut funktioniert, schreib ich das freqVectorsEdit Script so um, dass man die Mac-XX...plist auf den Schreibtisch bekommt und am X86PlatformPlugin selber nichts verändert wird. FreqVectorsEdit.sh wird ja sowieso nicht mehr weiter entwickelt...(Zitat von anonymous writer)Ich bin mir ziemlich sicher, das ist garnicht so gewollt, nur ist denke ich mal die ssdtprgen Methode veraltet. Das einzige was aus der …
-
(Zitat von Harper Lewis)Selbst dann verändert FreqVectorsEdit.sh die Daten... Du kannst es ja mal durchlaufen lassen und Original mit Patch vergleichen
-
Definitiv coole Sache! Hast du mal den default output mit dem freq-vector output verglichen? Würde mich ja interessieren, ob sich der Autor da auch Inspiration von Pike geholt hat oder an die Sache anders rangeht und wenn ja, welche Methode die besseren Frequencies provided Anyway ist die SSDT Methode aus der Wiki bis auf Plugin-Type veraltet, wir sollten sie durch einen einfachen Guide zu CPUFriend und den Frequency Scripts ersetzen. Die Anleitung/Vorgehensweise hier ist meiner Meinung nach zu …
-
Sehr interessant, danke fürs testen! Setzt man das Skript jetzt aber zB auf Battery-Improvement sollte sich was ändern, oder?
-
Das heißt die "Performance Preference" macht absolut keinen unterschied? Vielleicht noch in der Entwicklung?