SMBIOS iMac17,1 / Skylake i76700K und Powermanagement - wie funktioniert es richtig?

Die Geschichte ist zwar eine Weile her, wollte aber wissen, ob sich etwas neues ergeben hat.

Ehrlich gesagt, stört es mich, dass Intel Power Gadget mit dem Takt hin und her springt. Dabei tippe ich geraden nur diesen Text hier ab

Hmm, schade. Dachte gäbe mittlerweile eine Lösung.

@armut
Was macht dein Hack laut Aktivitätsanzeige ? Vielleicht hat er ja was zu tun und deshalb die Zacken.

Die Aktivitätsanzeige zeigt nichts besonderes. Das ist es, was mich irritiert!

Ich greife das Thema wegen dem hier nochmal auf:

Zitat von kuckkuck

Der einzige Sinn von CPUFriend ist dementsprechend andere FrequencyVectors als die im SMBios hinterlegten zu injecten.
Dementsprechend macht die Nutzung der Kext auch nur Sinn, wenn die Daten aus der genutzten X86-Plist auch verändert werden.

Zitat von rubenszy

Das einzige was Sinn macht mit dem kext ist, wenn du zB eine CPU hast die einem iMac18.3 gleicht, du aber das SMBios von einem iMac 14.2 eingegeben hast aber die FrequencyVectors von den iMac18.3 nutzen möchtest.

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) Wichtig: Davor von der entsprechenden Plist (zB Mac-FA842E06C61E91C5.plist) aus /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/X86PlatformPlugin.kext/Contents/Resources/ ein Backup machen
• Jetzt wurde die Plist im X86Plugin ersetzt. Diese neue Plist aus /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/X86PlatformPlugin.kext/Contents/Resources/ kopieren und sichern.
• Die alte, gebackupte Plist wieder nach /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/X86PlatformPlugin.kext/Contents/Resources/ einfügen, wir wollen nur das Produkt von freqVectorsEdit.sh haben
• Die durch freqVectorsEdit.sh erstellte Plist mit Xcode öffnen und gegebenenfalls den LFM und das Energy Power Profile, kurz EPP o.ä anpassen
• Mit ResourceConverter.sh eine SSDT oder Provider.kext mithilfe unserer gesicherten Plist (die durch freqVectorsEdit.sh erstellte und angepasste Plist) erstellen
• CPUFriend und SSDT/Kext einsetzen und schauen wie das Ergebnis für die CPU aussieht. Am besten die SSDT auch noch mit einer ssdtprgen-SSDT kombinieren, die den PluginType=1 setzt. Das X86PlatformPlugin muss jetzt unbedingt laut IOReg genutzt werden.

Edit:
Gerade mal ausprobiert, sehr interessant. Folgende Erkenntnisse soweit bei mir:

• Die CPU taktet viel häufiger runter auf 800 MHz. Das konnte sie zwar davor auch, macht es jetzt aber mindestens doppelt so häufig...
• Die CPU läuft ein wenig heißer, aber ich bekomme ebenfalls 2000 Punkte mehr im Geekbench Multicore
• Die CPU hat weniger verfügbare CPU States. Diese sind jetzt nur noch:

  
  

  
  

  • Lowest Frequency Mode (LFM): 800 MHz
  • Base Frequency: 4000 MHz
  • Max Turbo Frequency: 4400 MHz bzw. 4800 MHz

Also sowohl positives als auch negatives Ergebnis

Hi @kuckkuck,
Ich habe es getestet. Egal was ich mache mit Piker-Alpha geht der Wert nicht unter 1300 MHz. Nur mit HWPEnabler und sonst nichts geht der Wert runter auf 800 MHz.

Unter Windows gehts noch weiter runter auf 500 MHz. Das war der Grund warum ich es nochmals getestet habe. Diesen Wert habe ich unter OSX nie erreicht.

ssdt_data:

HWPEnabler:

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

Ja genau so. Auch das Limit rausgenommen "02 00 00 00 0D 00 00 00 01 00 00 00 00 00 00 00 (0x0d/1300MHz set as limit).".
Keine Änderung. 1300 min.

Nur mit dem HWPEnabler klappt es bei mir. Ist aber auch OK. Die Werte sind super. Das es unter Windows noch etwas weiter runter geht ist auch super, aber nich unbedingt nötig.

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?

Ich habe es mit 00 ohne Limit prpbiert. Aber ich teste das nochmal mit den 500 als Limit.

Hi @kuckkuck,

Hier nochmals eine Rückmeldung. Habe das ganze jetzt nochmals nach deiner Anleitung komplett neu gemacht.

> Mit freqVectorsEdit.sh eine gepatchte Mac-XXXXXXXXXX.plist erstellt.
> LVM angepasst auf 00 > 05 erzielt das gleiche Ergebnis
> Mit dem ResourceConverter.sh eine ssdt_data.dsl erstellt.
> Die "Method (_DSM, 4, NotSerialized)" aus der ssdt_data.dsl kopiert und in die bereits zuvor mit ssdtPRGen.sh erzeugte ssdt.aml eingefügt.

Ergebnis:
Habe jetzt die gleichen Werte wie mit HWPEnabler. 800 MHz min. 500 MHz werden nicht erreicht.

Trotzdem ist deine Anleitung ein voller Erfolg. Da nur so mit einer ssdt.aml diese Werte erreicht werden. Und das ganze ist zukunftssicher da ich auf meiner Mojave Testinstallation genau die gleichen Werte erreiche.

Ich werde das jetzt mal so mit der ssdt.aml und dem Kext CPUFriend.kext lassen da der HWPEnabler ab und zu Abgestürzt ist un dann hatte ich nur noch 3500 MHz und high Power Lüfter. Eventuell ist dieses Problem dann hiermit behoben.

Wenn ich im Übrigen ohne den Kext CPUFriend.kext starte erreiche ich wieder nur die 1300 MHz. Das ist der gleiche Wert wie mit der unveränderten ssdt.aml generiert mit ssdtPRGen.sh.
Keine Ahnung warum und auch nicht warum @Piker-Alpha das so voreingestellt hat. Für Laptops und dessen Batterie eher schlecht.

Ich würde Vorschlagen das du deine Anleitung ins WIKI packst, da ich denke es ist der einzige und richtige Weg um CPU Power Management zusammen mit einer ssdt.aml zu steuern.

Danke für deine Anleitung.

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

der gleiche Wert wie mit der unveränderten ssdt.aml generiert mit ssdtPRGen.sh.
Keine Ahnung warum und auch nicht warum @Piker-Alpha das so voreingestellt hat. Für Laptops und dessen Batterie eher schlecht.

Ich bin mir ziemlich sicher, das ist garnicht so gewollt, nur ist denke ich mal die ssdtprgen Methode veraltet. Das einzige was aus der SSDT heutzutage noch übernommen wird, ist der PluginType=1, welcher für die Nutzung der X86Platform FrequencyPlists sorgt. In diesen ist in deinem Fall eben 1300MHz von Apple für das jeweilige Modell als LFM eingetragen. Die SSDT (prgen) kann daran nichts mehr verändern und die einzige Möglichkeit ist dann entweder die X86Plugin Plist manuell anzupassen, oder eine andere Plist mit CPUFriend laden zu lassen.

freqVectorsEdit.sh verändert die Mac-XXXXXXXXXX.plist passend zum Prozessor. Ohne diese Änderungen erhalte ich ein falsches Ergebnisse mit meinem i7-7500U Prozessor und der angepassten Datei ssdt.aml und dem CPUFriend Kext. Teste es mal.

Zitat von Harper Lewis

Jau, dann so: Wenn es bereits eine Board-ID mit passender CPU gibt, dann sollte der erste Schritt nicht nötig sein.

Selbst dann verändert FreqVectorsEdit.sh die Daten... Du kannst es ja mal durchlaufen lassen und Original mit Patch vergleichen