Beiträge von Brumbaer

    Ein einfacher Test ist es das Intel Power Gadget laufen zu lassen. Das gibt es für beide Plattformen.

    Es zeigt die die CPU Temperatur und die Leistungsaufnahme an.

    Dann lässt du Prime mit den selben Parametern laufen (4 Threads, Min FFT 100, max. FFT 100, rest bleibt).

    Ist die Leistungsaufnahme in etwa gleich ? Sollte sie. Wenn nicht ändere die FFT Werte (beide gleichen Wert) bei einer Platform so, dass die Leistungsaufnahmen in etwa gleich sind.

    Ist die CPU Temperatur bei gleicher Leistungsaufnahme (hoher Leistungsaufnahme nicht Idle) gleich ?

    Falls nicht, kannst du hören ob bei niedrigerer Temperatur die Lüfter schneller laufen ?


    Sind die Lüfter am mobo oder der AIO angeschlossen ?

    DSM2

    Die Geekbench Werte sind ungewöhnlich.

    Bei identischen Bedingungen sollten die Single Thread Werte im Rahmen der Messgenauigkeit identisch sein und die Multithred Werte 25 bis 30% auseinander liegen.


    Es sieht für mich so aus, als seien die Multiplier unterschiedlich gesetzt oder es war ein weiterer Prozess am werkeln.


    Ein schneller Check im Internet bestätigt das die Single Thread Werte etwa gleich sein sollten.

    Alles IMHO, ich habe keine Beziehung zu der Bauer und habe das Ding gekauft.


    Seit ewigen Zeiten wurde bei den Intel Consumer Prozessoren die Qualität der Wärmeübertragung zwischen IHS(Integrated Heat Spreader) und Die durch die Qualität der Wärmeleitpaste bestimmt.

    Durch Ersetzen der Original Wärmeleitpaste konnte man die Wärmeübertragung deutlich verbessern und so den Prozessor kühler betreiben. Das erlaubt u.a. höhere Frequenzen beim Übertakten.


    Der 9900K packt erstmals (bei einer Intel Consumer CPU) 8 Kerne auf den Die. Die produzieren bei gleicher Taktfrequenz und Auslastung mehr Wärme als 6 Kerne. Um die Wärme besser abführen zu können verwendet man keine Wärmeleitpaste sondern verlötet den Die mit dem IHS.


    Kurz nach dem Erscheinen des 9900K wurde eine Welle losgetreten, dass das nicht so gut funktioniert wie man erwartet. Allen voran der Bauer, der über die mangelnde Qualität berichtete und die Wärmeableitung dadurch verbesserte, dass er die Lötverbindung entfernte, die Kontaktflächen von Die und IHS glatt schliff und dann dann Flüssigmetall als Wärmeleitmittel aufbrachte. Das brachte in seinem Test 9 Grad niedrigerer Temperaturen. Nachdem er den IHS noch etwas verdünnt hat kam er auf einen Gewinn von 13.5 Grad. Das ist ok.


    Ich habe nur einen 9900K im Einsatz und muss sagen, ich war mit der Temperatur mehr als zufrieden. Bei 230W 88 Grad ist zumindest so gut wie Alles was ich vorher auch mit Flüssigmetall erreicht hatte und liegt im Groben im Bereich der Temperaturen, die der Bauer mit seinem Exemplar nach dem Ersetzen der Lötverbindung (ohne Verdünnen des IHS) erreicht hat.

    Deshalb kam mir nie der Gedanke bei meinem 9900K die Lötverbindung zu ersetzen.


    Nun bin ich über eine Produktankündigung von der Bauer gestolpert in der ein OC-Frame für i9 beworben wird. Die Idee ist es den IHS zu entfernen und den CPU-Kühler direkt mit dem Die in Kontakt zu bringen. Dazu muss man die CPU allerdings anders als bisher im Sockel fixieren, da der normal Spannmechanismus am IHS ansetzt und der Die außerdem tief im Spannmechanismus sitzt, der somit dem Kontakt mit dem CPU-Kühler im Wege steht. Der Bauer OC-Frame ist ein Rahmen der die CPU in den Sockel drückt und so flach ist, dass der Die ein Zehntel mm darüber hinausragt.

    Das hat meine Neugier geweckt und so habe ich beschlossen es auszuprobieren.


    Das Entfernen des IHS geht mit einem geeigneten Werkzeug einfach. Es bleiben allerdings Reste des Lötzinns auf dem Die. Diese muss man entfernen. Ich habe dazu Schleifpapier verschiedener Körnung verwendet. Der Prozess ist mühsam und man sieht dass es auch auf der Platine seine Spuren hinterlassen hat.

    Das Entfernen des Klebers mit dem der IHS zusätzlich fixiert war ist einfach und nur dort nötig, wo der Frame aufliegt.

    Das Entfernen des alten Spannmechanismuses und das Befestigen der CPU mit dem OC-Frame ist denkbar einfach. Dann eine ganz dünne Schicht Flüssigmetall auf den Die und die Kontaktfläche des Kühlers.




    Und schon geht der Ärger los. Viele CPU Kühler haben Vorrichtungen die verhindern, dass der Kühlkörper zu fest auf die CPU drückt. Diese blockieren den Kühlkörper in einem bestimmten Abstand vom Mainboard. Dummerweise ist der Kontaktpunkt zwischen CPU und Kühler nun ein paar mm tiefer und so bleibt ein Spalt zwischen beiden. Man muss in so einem Fall die Original Haltebolzen/Schrauben durch einfache Schrauben ersetzen, die es erlauben den Kühler entsprechend "tiefer zu legen".


    Mit Geduld und Spucke geht Alles, bleibt die Frage, was hat es gebracht? 4, vielleicht 5 Grad. Hmmmmmm. Ich dachte "hab ich wohl was falsch gemacht". Aber nein, in einem Video erklärt der Bauer, dass der zu erwartende Gewinn zwischen 4 und 10 Grad liegt.

    Es ist nicht auszuschliessen, dass sich das Ergebnis nach weiteren Schleifvorgängen verbessern lässt. aber irgendwie glaube ich nicht daran.


    Wenn man nicht auf der Jagd nach dem letzten Hertz ist, sind der Aufwand und die Gefahr die CPU zu beschädigen zu groß. Ich würde es beim Verdacht schon eine "relativ kühle" CPU zu haben nicht noch einmal tun.

    Man kann allerdings den OC Frame und eine geköpfte CPU im Bundle kaufen, was einem richtig Arbeit sparen würde. Allerdings weiß ich nich in wie weit die Lötverbindung abgeschliffen wurde.

    Ich habe eine gute und eine schlechte Nachricht.


    Die gute ist, dass was wir bisher alles richtig gemacht haben und es mit einer Ergänzung läuft.

    Die schlechte ist, ich weiß nicht warum.


    Im Anhang ist dein Kext. Ich habe nur einen zweiten PropertyPatch(unter IOKitProperties) eingefügt. Dieser ist für die CPU, aber man kann auch einen anderen nehmen, aber auch nicht jeden. Ein Verdoppeln des Audio Eintrages funktioniert z.B. nicht.


    Mit dem zusätzlichen Patch funktioniert auf meinem System dein Kext.

    Mein Kext hat auf Anhieb funktioniert, weil in meinem Kext von Anfang an weitere Patches vorhanden waren.


    Ich habe kenie Ahnung warum das so ist, vielleicht eine Racing Condition. Ich werde versuchen es rauszubekommen.

    Aber zuerst möchte ich dich bitten zu testen ob das beiliegende Kext bei dir funktioniert.

    Ja, aber es könnte theoretisch sein, dass es jemand wieder überschreibt. Und Frank ist sicher.


    Das sollte jetzt funktionieren.


    Zippe bitte das Kext und lade es hoch. Ich würde gerne überprüfen ob irgendetwas fehlt ?

    Das Kext ist im Other Ordner des kexts Ordners des CLOVER Ordners des EFI Ordners der EFI Partition von der du startest ?

    Du hast das Kext nicht über Clover disabled ?

    Das ist das falsche Device. Ich wollte das IOHDACodecDevice unter HDEF sehen.


    Um deine Frage zu beantworten.

    PropertyInjector versucht den Wert für alle Services auf die die Match Bedingungen zutreffen zu ändern. Doof wenn man mehrere hat, aber nur einen ändern will.

    Die Einschränkung an Hand von IOHDACodecVendorID macht Sinn, damit man nur das eine IOHDACodecDevice ändert .

    Da wie aber keine Subklasse von IOPCIDevice haben funktioniert IOPrimaryMatch nicht.

    Es gibt aber die Möglichkeit auf einen beliebigen Eintrag zu matchen.

    Man legt zusätzlich zu IOProviderClass einen Eintrag Namens IOPropertyMatch an. Dieser muss vom Typ Dictionary sein.

    In diesem Dictionary listet man alle Eigenschaften mit dem Wert auf, den man erfüllt haben will.

    In unserem Fall IOHDACodecVendorID und der Wert 0x10ec1220. Den Datentyp beachten.


    Das sieht dann so aus:



    XCode macht aus der Hexzahl eine Dezimalzahl, deshalb steht da 283906592.


    Eine einfache Methode zu testen ob das Matching klappt ist es eine zusätzliche Eigenschaft zu definieren.

    Z.B.

    Name: Frank

    Typ: String

    Data: "was here"


    Wenn das matching funktioniert wird der Eintrag im IOHDACodecDevice zu sehen sein.

    Wie gesagt eine Klasse kann alles mögliche sein z.B. ein Gruppenname, aber die Klasse die einen Service realisiert ist eine Klasse im Sinner der Object Orientierten Programmierung.


    Ich habe über Stunden hinweg ohne auf Programmierkenntnisse zurückzugreifen versucht zu beschreiben was eine Klasse ist und ich bin gescheitert.


    Letztendlich ist eine Klasse ein Programmstück, das Instanzen von sich erzeugen kann und definiert was die Instanzen können (Interface) und wie sie es tun (Implementation).

    Da Klassen Programmstücke sind, werden sie von einem Programmierer erstellt, mit dem Ziel eine bestimmte Aufgabe zu erfüllen.

    Andere Klassen oder Programmstücke können auf Instanzen einer Klasse zugreifen und mit ihnen arbeiten, denn wie das geht sagt ihnen das Klassen Interface.

    Weiss man welcher Klasse eine Instanz angehört, weiss man wie man mit ihr arbeiten kann ohne zu wissen zu müssen wie sie es genau tut.


    Es gibt Mechanismen in macos, die Treiber laden. Die Treiber sind Instanzen von Treiberklassen.

    Die Instanzen werden erzeugt und melden dann dem Betriebssystem, dass sie da sind.

    Hat man nun ein Gerät, dass eine Instanz einer Klasse lädt, die macos nicht kannte als es erstellt wurde, sieht man alt aus, denn macos kennt ja das Klasseninterface nicht, da es die Klasse noch nicht gab als es erstellt wurde.


    Da kommt die Vererbung ins Spiel. Man erzeugt Klassen, die aufeinander aufbauen. Die erste Klasse ist zum Beispiel vom Typ Treiber und beschreibt in ihrem Interface alles was ein beliebiger Treiber kennen muss.

    Nun legt man für bestimmte Gerätegruppen Unterklassen an. Die Unterklasse (Subclass) erbt das Interface ihrer Superklasse(Superclass).

    Die Subclass erbt auch die Implementation (den Programmcode) ihrer Superklasse, kann die aber durch eigens auf sie angepassten Code ersetzen.

    Bei Treibern wären das z.B. Klassen für USB, Netzwerk, Grafik. Jeder dieser Treiber hätte wieder Unterklassen, bei den USB Klassen z.B. für verschieden Chipsätze unterschiedliche Treiber.


    Hat man nun einen Computer mit einem macos unbekannten USB Chipsatz und einem passenden Kext dazu, so wird über den vorhin erwähnten Mechanismus eine Instanz der Klasse erzeugt, die macos nicht kennt. Aber da es sich um einen USB Chipsatz Treiber handelt, ist er eine Unterklasse der USB Klasse und davon kennt macos das Interface und kann also damit arbeiten.


    Im IORegistryExplorer kann man die Superklassen einer Klasse sehen.



    Die Klasse AppleACPIPCI basiert auf IOPCIBridge das auf IOService basiert usw.

    Alle Treiber sind Unterklassen von IOService, das eine Unterklasse von IORegistryEntry, das eine Unterklasse von OSObject ist.


    OSObject stellt Standardfunktionalität für Objekte im Kernel zur Verfügung. Das betrifft hauptsächlich die Speicherverwaltung, also wie man Objekte anlegt und löscht.

    IORegistryEntry erweitert OSObject um Funktionen die ein Verwalten der Objekte in der IORegistry erlauben. Anlegen, verschieben und Löschen von Einträgen uä.

    IOService fügt dann alles hinzu was jeder Service können muss. das ist ein A-voll Zeug wens interessiert, der kann's googeln.



    Wir wissen das die Eigenschaft die wir ändern wollen IOHDACodecRevisionID heißt.

    Diese kommt in IOHDACodecDevice vor.


    Es besteht die Möglichkeit, dass die Eigenschaft von einem anderen Service übergeben wird. Aber das interessiert und erst, wenn das Ändern an der Stelle nicht funktioniert.




    So an der Stelle haben wir die Instanz und die Klasse.

    Die Klasse lautet ........... ?


    Verwendet man IOProviderClass für das matching so wird man über jeden Service informiert, der der Klasse oder eine Unterklasse davon entspricht.

    Gibt es mehrere Instanzen einer Klasse z.B. IOService, kann man die "Matches" weiter einschränken. Das ist dann der Schritt nachdem wir die Klasse bestimmt haben haben.



    Ich verstehe die IORegistry Frage nicht.

    HDEF@1F,3 und AppleHDAController@1F,3 sind unterschiedlicher Services.

    Was meinst du mit unterschiedlichen Ansichten ? Service vs. ACPI ?

    Richtig verstehen: “Service”

    Service, Programm, Treiber…


    Dummerweise ist der Sprachgebrauch nicht eineindeutig. Wenn man von einem Service spricht kann es sein, dass man den Service im allgemeinen oder im Besonderen spricht.

    Vergleichen wir ihn mit einem Programm, was ganz gut passt, denn letztendlich ist er eins.

    Pages im allgemeinen ist ein Schreibprogramm mit folgenden Möglichkeiten ....... Es liegt in meinem Programme Ordner.

    Sobald ich Pages starte wird es geladen und ausgeführt und dieser laufende Code ist eine Instanz von Pages. Mit etwas Getrickse kann ich das Programm mehrmals starten und die Kopien parallel laufen lassen. Dann habe ich mehrere Instanzen von Pages gleichzeitig laufen.

    So ist es auch mit Services. Es gibt den Service im Allgemeinen und dann gibt es Instanzen davon, also Code der ausgeführt wird. Es kann mehrere Instanzen des selben Service gleichzeitig geben.


    Services werden programmtechnisch als Klassen realisiert. Entsprechend ist eine Instanz eines Service eine Instanz seiner Klasse.


    Eine Instanz eines Service kann unter einem anderen Namen laufen, als dem Klassennamen.


    IOProviderClass = Name eines Services als Startsignal

    D.h. wird ein Service dieses Namens oder eine Subklasse davon geladen, dann startet die Überprüfung.

    Ja, aber. Genau genommen ist es der Name der Klasse die den Service realisiert. Es ist denkbar, dass der Service und Klassenname sich unterscheiden. Und Instanzen eines Service müssen auch nicht den gleichen Namen haben wie der Service. Also muss man darauf bestehen, dass dies der Name der Klasse ist.


    CFBundleIdentifier = Programmcode des Service

    "zB. com.apple.driver.usb.AppleUSBXHCIPCI"

    kann mehrere Services enthalten..

    Richtig


    IOClass = “spezifiziert den Service im Bundle”

    Wieder das Namen-Problem. Es handelt sich um den Namen der Klasse, die den Service realisiert.


    Richtig verstehen: “Klasse”

    Gerät, Klasse, Art…

    Ergibt sich aus dem Zusammenhang. Eine PCI Klasse ist etwas anderes als eine Klasse (Konzept in der Object-orientierten-Programmierung) die einen Service realisiert.


    IOPCIClassMatch = “GeräteKLASSE”

    -> GeräteKLASSE = Name d. (PCI) Gerätes

    Nein. Das ist eine PCI-Geräte spezifische Klasseneinteilung. Sie dient dazu PCI Geräte einer Gruppe zuzuordnen. Grafikkarten, Kommunikationskarten etc.. Gibt es für eine Klasse von Geräten verbindliche Vorschriften für die Funktion und wie sie bereit gestellt wird, so kann man Treiber schreiben, die dann an Hand der Geräte Klasse geladen werden ohne dass man einen Treiber für jedes Gerät schreiben muss. man muss nicht einmal die Geräte-Id jedes einzelnen Gerätes kennen und eintragen.


    IOPCIPrimaryMatch = “GeräteID”

    Produkt und Hersteller ID eines PCI Gerätes. Wieder etwas was nur für PCI Geräte bzw. Services die PCI Geräten zugeordnet sind Bedeutung hat. Das gleiche Konzept gibt es u.a. bei USB Geräten.


    IORegistry, verstehen..


    IOService (Plane): Auflistung der installierten Services! (Die an Geräte gebunden sind)

    Jein. Für gewöhnlich schon, aber ein Service kann auch einfach nur ein Programmstück sein, das nicht an ein Gerät gebunden ist.


    Jede Zeile auf der linken Seite ist also ein "Service"?

    Ja


    IOACPIPlane: Geräte..

    Die Einträge in der linken Spalte, sind Einträge, die macos in der DSDT gefunden hat. Das können auch Einträge sein, für die später keine Services geladen werden.



    AppleALC verwendet die Eigenschaft IOHDACodecRevisionID um Patches zu identifizieren.

    Deren Wert wollen wir anpassen.

    Wir kennen den Namen der Eigenschaft.

    Nun müssen wir rausfinden in welcher Instanz die Eigenschaft vorkommt.


    Dann legen wir einen PropertyInjector Eintrag, der gestartet wird sobald diese Instanz erzeugt wird, an.

    Dazu müssen wir wissen, welche Instanz die Eigenschaft enthält und von welcher Klasse es eine Instanz ist - denn wir verwenden IOProviderClass um das Erzeugen der Instanz zu erkennen und IOProviderClass will den Klassennamen haben.

    Du hast einen IORegistry-Auszug gepostet. Indem kommt der Eintrag IOHDACodecRevisionID vor.

    Das ist der der geändert werden muss.

    In welchem Service kommt er vor und wie heisst die Klasse ?

    Wo im Fenster des IORegistryExplorers steht der Service ?

    Wo im Fenster des IORegistryExplorers steht die Klasse ? Du weisst wie die Klassen eines PCIDevices heisst, also könntest du ein PCI Device anwählen und schauen wo die Klasse im Fenster zu finden ist.

    Gerät bedeutet nicht zwangsweise ein Gerät im Umgangssprachlichen Sinne.

    Um genau zu sein hätte ich den Audruck Service verwenden sollen.

    Bei welchem Service (Eintrag im IORegistry Baum im Anzeigemode Service) kommt das Feld, das du ändern willst, vor ?

    Wenn du den kennst, brauchst du seinen Klassennamen. Den zeigt dir der IORegistryexplorer auch an.

    Die Revision ID gehört zum IOHDACodecDevice und wird dort im Feld IOHDACodecRevisionID gespeichert.


    Die RevisionId, muss von AppleALC unterstützt werden. Auf der AppleALC Website gibt es zu jedem Chip eine Info.plist in der stehen u.a. die unterstützten Revision IDs.


    Du musst nun nur noch dafür sorgen, dass eine dieser RevisionIDs in oben genanntem Feld landet. Das kann z.B. PropertyInjector.

    Oder du trägst deine RevisionID in der Info.plist ein und kompilierst dir dein eigenes AppleALC.

    Nur Rechner (9900K@5200, Vega 64 Frontier):


    Idle 70W

    Luxmark Ball-CPU+GPU 500W bei 31500 Punkten das sind 63 Punkte pro Watt.


    kaneske hatte die gute Idee mit Luxmark CPU + GPUs zu testen.

    Damit hat man neben Idle eine weitere leicht nachzuvollziehende Testmethode.

    Wenn man dann noch das Luxmark Ergebnis durch die Watt teilt hat man einen Vergleichswert für die Effizienz der einzelnen Rechner.