Beiträge von Brumbaer

  • Was ist GPRW und wenn ja, wieviele ;-)

    ACPI kennt GPEs General Purpose Events. Die Events können durch alles mögliche ausgelöst werden u.a. Power Taste, Serielle Schnittstelle.

    Jeder dieser Events hat eine Nummer. Die Nummern sind nicht standardisiert, aber es gibt gebräuchliche Nummern.

    0x6D wird u.a. von LAN und USB verwendet.

    0x0D müsste ich nachschauen.


    Geräten sind _PWR Methoden zugeordnet, die bestimmen aus welchem Sleep State ein Gerät ein Wake auslösen kann.

    Die _PWR wird nicht in der DSDT oder SSDT aufgerufen sondern vom Host Computer aus. Was der mit der Info macht ist seine Sache.

    Diese _PWR Methode ruft für gewöhnlich GPRW mit der Eventnummer und Sleep State als Argumenten auf.


    Beim Mac muss, bei Abfragen für bestimmte Events, 0 als zweiter Wert zurückkommen.


    Wir haben aber gesehen, dass in der Originalversion, die über die ich geschrieben habe, solange irgendein Sleep State enabled ist, immer ein Wert zwischen 1 und 4 im zweiten Wert zurück kommt (entweder der Wert in Argument1 oder der höchste enabelte Sleep State).


    Die neue Version, die im ersten Post, schaut nach ob das Argument0 einer dieser Events ist und ob es sich um einen Rechner mit Darwin handelt.

    Trifft beides zu gibt es Argument0 im ersten Wert (wie sonst auch) und 0 im zweiten Wert (Statt dem abgefragtem, bzw. dem höchsten möglichen Sleep Wert) zurück.

    Statt eine extra Variable (PRWP in der Originalversion) anzulegen gibt die neue Funktion die Werte direkt als Package zurück - das ist nur Kosmetik.


    Ist Argument0 keiner der beiden Eventnummern oder ist es kein Rechner mit Darwin, dann wir die Originalfunktion verwendet.

  • Was ist GPRW und wenn ja, wieviele ;-)

    Arg0 Ein Wert der "durchgereicht wird"

    Arg1 ist die Nummer des Sleep States der abgefragt werden soll - gibt man etwas an was es nicht gibt bekommt man den höchsten möglichen Sleep State zurück


    Das Ergebnis landet in PRWP Feld aus 2 Werten, das am Ende ausgegeben wird.


    Zuerst wird der erste Wert von PRWP auf den Wert des ersten Argumentes gesetzt.


    SS1 bis SS4 sind Bits in denen das BIOS angibt welche der 4 Sleep States enabled sind. Die Bits werden zu einem Bitfeld gemacht, das in local 0 gespeichert wird und zwar landet das Enable Bit des SSx im xten Bit von local0.

    SS1 wird geholt um 1 verschoben. SS2 wird um 2 verschoben usw. und alle Bits werden in einem Wert zusammengefasst (geodert)


    Das alles nur damit man mit nur einer if Abfrage feststellen kann ob der Sleep State mit der Nummer die dem Wert in Arg1 entspricht gesetzt ist. Sprich ob dieser Sleep State enabled it.


    Ist dem so wird die Nummer des Sleep States im 2 Wert von PRWP abgelegt.


    Ist dieser Sleep State nicht gesetzt, wird bestimmt welches das am höchsten gesetzte Bit ist, als was der höchste enabledete Sleep State ist und dessen Wert im 2 Wert von PRWP abgelegt. FindSetLeftBit zählt von der 1 aus nicht von der 0 wie Arg1, deshalb wird vorher local0 einmal nach rechts geschoben damit das Ergebnis mit der Zählweise von Arg1 kompatibel ist.


    Dann wird PRWP ausgegeben.

  • Fritzbox 7490 IPTV WLAN

    Ich habe seit einiger Zeit Probleme mit IPTV am Mac, ein Gestottere wie ein Jüngling beim ersten Rendezvous (na ja vielleicht ist das heute nicht mehr so). Zuerst dachte ich es sei die OSX Beta (welche auch immer gerade aktuell ist), aber nein keine Änderung.

    Im Nachhinein war die Umstellung von Powerline auf WLan das Problem. Nur habe ich die Verbindung seinerzeit nicht hergestellt.

    Es gibt bei AVM eine Seite mit Labortreibern https://avm.de/fritz-labor/fri…isch-aus-der-entwicklung/, sowas ähnliches wie nightly builds.

    Für die 7490 steht in den Verbesserungen/Änderungen

    Zitat
    • Behoben - Probleme bei der Verarbeitung von Multicast-Paketen behoben, z. B. für IPTV-Anwendungen zwischen WLAN-Geräten (7490)

    Und ich kann bestätigen, nach Aufspielen der Firmware sind die IPTV Probleme verschwunden.

    Das ist keine Aufforderung Beta Firmware aufzuspielen, und wer es macht, macht es auf eigene Gefahr, etc.. Es ist nur ein Hinweis, dass es eine Firmware gibt, die das Problem zu beseitigen scheint, ob man sie ausprobiert bleibt jedem selbst überlassen.

  • mit "geklauten" EFI's prahlen - Wie seht Ihr das?

    Alles IMHO:


    "Mein" Auto ist "mein" Auto, nur weil ich es besitze, auch wenn ich es nicht selbst hergestellt habe.

    "Meine" EFI ist "meine" EFI, weil ich sie verwende.


    Ab wann kann man sagen, man habe etwas selbstgemacht ?

    In der Industrie gibt es Förderungen, wenn etwas an einem bestimmten Ort produziert oder veredelt wird. Diese Förderung wird/wurde auch gezahlt, wenn das Produkt irgendwo anders gefertigt wurde und nur noch eine letzte Handlung z.B. die letzte Schraube reingedreht am "Geförderort" vollzogen wurde.

    Unter dem Gesichtspunkt hat jeder der ein einzelnes Flag in einer Config oder einen Buchstaben in einer SSDT ändert, die EFI "selbst gemacht".


    Oft ist es doch dieses eine Flag, dass die EFI plötzlich funktionieren lässt, und dann macht es den Unterschied, egal was alle anderen vorher gemacht haben. Dann hat "meine" Änderung es zum Laufen gebracht.


    Solange jemand eine, egal wie klein sie auch sein mag, Änderung gemacht hat, die letztendlich die gewünschte Funktionalität herstellt, hat er das Recht zu sagen, dass er die EFI erstellt hat.


    Und machen wir uns nichts vor niemand erstellt eine EFI komplett selbst. Es geht schon mit der Verwendung der in der Doku vorgeschlagenen Einstellungen los. Dann werden SSDT's und Kexte für bestimmte Probleme kopiert. Und Flags gesetzt, von denen man weiß, dass die in der gegebenen Situation "helfen". Kaum einer entwickelt so etwas von Grund auf, alle greifen auf bestehendes Wissen zurück. Oft startet man sogar mit einer existierenden EFI - ob eigene oder fremde.


    Wenn jemand eine EFI nicht zu 100% kopiert hat und nur ein Flag geändert hat, das zur Funktionsfähigkeit führt, hat er das Recht zu sagen er habe sie gemacht.

    Es ist IMHO ungerechtfertigter verletzter Stolz zu sagen "ich habe aber mehr dazu beigetragen". Zumal die eigene Vorarbeit ja auch wieder auf der Vorarbeit anderer beruht, was man gerne vergisst.


    Und wenn jemand tatsächlich etwas einfach 1 zu 1 kopiert, und sich mit "fremden" Federn schmückt verletzt es den Stolz des "Urhebers" zurecht.

    Dann kann sollte der Urheber es ignorieren oder ihn konfrontieren. Alles andere scheint mir schlecht fürs Karma :)


    Und niemand will lesen:

    EFI XYZ, Flags a, b, c von mir, d und e ursprünglich von x .... SSDT ursprünglich von .. geändert in Zeile 5 durch .... und in Zeile 7 von ....

  • Ich hab's getan: Mein Hackintosh geht in den Ruhestand

    Ich benutze momentan auch hauptsächlich meinen Mac Mini mit M1. Aber es ist eher Sturheit als eine rationale Entscheidung.

    Dass der M1 Programme schneller öffnet kann ich nicht nachvollziehen - er startet sie gefühlt eher langsamer als mein Hack - Intel Programme vielleicht etwas deutlich langsamer. Das M1 System startet schneller - bei einem Kaltstart. Aus dem Deep Sleep ist es wieder schwer zu sagen. Ich könnte es messen, aber es fühlt sich nicht schneller an. Mein Hack baut nach jedem Neustart den Spotlight Index neu auf oder updated ihn zumindest. Ich dachte das läge daran, dass beim Original irgendwas anders wäre, aber der Mini macht das gleiche.

    Zwei bestimmte Apps sind spürbar langsamer auf dem M1 und ich befürchte, da wird es so bald auch keine "Nativ Version" geben - ich hoffe auf mehr Performance Kerne im nächsten Jahr. Ansonsten gibt es gefühlt keinen bzw. keinen nennenswerten Geschwindigkeitsunterschied.

    Die Anzahl an Anschlüssen genügt mir. Ich habe nur einen Bildschirm, Aktivboxen, Kartenleser, Backuplaufwerk, Keyboard Touchpad am Rechner. Die letzten zwei sind auch noch über einen Hub im Bildschirm angeschlossen. Ich brauche nicht einmal einen zusätzlichen Hub. Laser-Drucker, Scanner, 3D Drucker etc. sind über das Netzwerk (Ethernet) angeschlossen.

    Also es gibt für mich keinen Grund meinen Hack durch den Mini zu ersetzen. Es wäre eher sinnvoll den M1 wieder zu verkaufen und auf den Nachfolger zu warten.

    Auf der anderen Seite hat der Mini einen Vorteil :)

    Zwei Systeme mit gefühlt vergleichbarer Leistung.

    Der Hack ist in Multithread Benchmarks 1.5 bis über 2.0 mal so schnell, aber in Apps merke ich es nur selten. Bei der GPU ist der Unterschied noch krasser, aber ich habe bisher nur eine App benutzt bei der es deutlich zum Tragen kam. Es gibt bestimmt mehr, aber wenn keiner den Baum sieht wenn er umfällt ...


    Und es ist absolut faszinierend, den Größenunterschied der beiden Systeme zu sehen.


    Frohe und gesunde Feiertage

  • Final Cut und 10 Gigabit Netzwerk

    _homm_

    Ich nehme an, das sind die Netwerktransferraten laut Aktivitätsanzeige oder eines anderen Tools.


    Die 480MB/s ist was deine System-Combo zu leisten vermag. Die 80MB/s kommen dadurch zu Stande, dass dein Projekt nicht eine Datei, sondern ein Verzeichnis ist. Immer wenn eine Datei zu Ende ist und die nächste gestartet wird, gibt es eine "Pause" weil verschiedene Verwaltungsarbeiten ausgeführt werden.


    Wenn du dein Projekt zippsed und die Zip Datei überträgst, solltest du auf die volle Datenübertragungsrate kommen.


    Wenn du die Zeit in Minuten misst, sollte der Unterschied nicht so deutlich sein.

  • „One more thing“ Apple Event 10. November

    Um eins klarzustellen, das Ram ist nicht auf dem selben Wafer wie der M1, es ist nur im gleichen Gehäuse.

    Man sieht es an den Bildern und auch in den Zahlen. Der M1 hat 16 Milliarden (amerik. Billionen) Transistoren. Eine 1 Bit dynamische Ramzelle braucht 1 Transistor. D.h. 16 GB Speicher brauchen 16 * 1024 * 1024 * 1024 * 8 Transistoren. Also mehr als 8 mal so viele Transistoren, wie ein M1 hat.

    Es gibt also schon jetzt ein Interface zwischen "externem" DRAM und dem M1. Es ist bestimmt nicht identisch zu dem Interface, wie es für externes DRAM designed würde, aber es ist für Apple's Ingenieure kein Problem den Funktionsblock auszutauschen.

    Es ist fraglich ob Apple für jede mögliche Speicherkonfiguration einen Extra Baustein anbieten wollte. Und aus logistischen Gründen ist es möglicherweise einfacher das Ram als getrenntes Bauteil auszuführen. Es ist nicht auszuschließen, dass das Interface mit "normalem" DRAM Performanceverluste mit sich bringen würde, weil das Interface dem "Standard" folgen müsste, während Apple mit DRAM im selben Gehäuse und dessen Anbindung Abläufe optimieren könnte.

    Die Verwendung einer GPU mit externem DRAM ist dafür mglw. einfacher als mit "internem".

    Wie man sieht weiß man nichts genaues.

    Aber mir scheint sicher, wir werden mehr Performance Kerne in der CPU sehen. Bei der GPU bin ich mir kurzfristig nicht so sicher. Mein Tip wäre eine mittlere Konfiguration mit z.B. 32K Speicher fest und etwas schnellerer GPU; und eventuell eine "Pro" mit externem DRAM und externer GPU. Aber vielleicht sagt sich Apple auch die Mxe gibt es nur mit internem RAM und GPU und wer noch mehr Leistung will muss noch ein Jahr oder zwei länger warten.

    Wir werden sehen, es bleibt auf jeden Fall spannend.

  • „One more thing“ Apple Event 10. November

    TheWachowski

    Das Luxmark zeigt, dass zumindest nichts offensichtlich falsch ist mit der Config deiner Karten.


    Ich sach ma so.


    Der BRT zeigt auf meinem System im Normalfall 57/87

    Ich kann die Anzahl Lanes nicht verändern, aber ich kann Gen2 statt Gen3 als Übetragungsmodus wählen.

    Die Übertragungsgeschwindigkeit der 16 Lanes sinken von 15,5GB/s auf 8GB/s. Der Wert sollte nun auf 57/46 fallen, tut er aber nicht. Er fällt nur auf 57/67. Also hat die Datenübertragungsgeschwindigkeit eine Auswirkung.


    Schauen wir uns die oben geposteten Screenshots an.

    Was gemessen wird ist die Anzahl der Frames/s.

    Man kann erwarten daß innerhalb einer Testgruppe BRAW12:1 in einer Sekunde immer die gleiche Datenmenge durch die GPU geht.

    Innerhalb einer Gruppe werden FPS Raten für verschiedene Formate angegeben. 4K hat 4 * so viele Pixel wie HD, also sollte die Datenrate auch nur ein Viertel betragen. Analog 8k zu HD ein Sechszehntel.

    Und siehe da es passt.

    Wir können uns also auf einen Wert jeder Testgruppe beschränken, ich nehm den ersten den HD Wert.

    12:1 hat die höchste Rechenzeit, aber die geringste zu übertragene Datenmenge.

    3:1 hat die kürzeste Rechenzeit, aber die größte zu übertragene Datenmenge.

    Das Datenaufkommen zwischen den Gruppen Datenaufkommen 1,0; 1,5; 2,4; 4. Der genau Faktor hängt vom Datenstrom ab, aber generell passt es.


    Ich habe mal den Anteil der Datenübertragung bezogen auf den theoretisch möglichen Wert bestimmt.


    Man sollte annehmen, dass mit abnehmenden Kompressionsfaktor, der Prozentsatz steigt. Denn die zu übertragenden Daten wachsen und die Rechenzeit pro Bild sinkt.

    Auffällig ist, dass díes nur für die Vega Frontier mit 10900K zutrifft. Bei den anderen Systemen sinkt der Prozentsatz für BRAW3:1.

    Beim 8700K ist auch BRAW 5:1 niedrig.

    Meine erste Vermutung war, dass es am Treiber liegt, falsch.

    Ich habe den 10900K auf 6 Kerne beschränkt und siehe da, der Prozentsatz sinkt nun auch bei der Vega.

    D.h. Der Prozessor ist der Bottleneck. Das würde auch das Verhalten des 8700K bei BRAW5:1 erklären.


    Ok zurück zum Ausgangsproblem.

    Schauen wir uns die Systeme mit Vega 64 und Vega 7 an, sehen wir, dass der Grad der ausgenutzten Datenübertragung sich im selben Bereich befindet. D.h. eine Vega 7 schafft es bei BRAW12:1 etwa 66% der theoretischen Datenübertragungsrate der der GPU zur Verfügung stehenden Lanes zu nutzen. Das System mit 8700K auch etwas weniger, weil der Prozessor langsamer ist, weshalb er auch schon bei BRAW5:1 einknickt.

    Dass das System mit den 2 Vega 64 bei 62% liegt kann an der Vega selbst oder der Aufteilung der Berechnungen auf 2 GPUs liegen. Ist aber unwesentlich.

    Hat man zwei Vegas, so können sie immer noch 66% der Bandbreite nutzen. Das Problem ist im 9900K System ist die Bandbreite 15.5GB/s egal ob man eine oder zwei Karten verwendet, weil sie sich 16 Lanes teilen. Beim 10980XE ist es anders. Da sind es 66% von 31GB/s (natürlich nur wenn man zwei Karten hat).

    Da der FPS Wert sich direkt aus der Datenübertragungsrate ergibt bedeutet 66% von 31,5 ergibt den doppelten Wert wie 66% von 15,75.


    Also ja, ich denke es liegt nicht an der Konfiguration, sondern nur an den Lanes.

  • „One more thing“ Apple Event 10. November

    TheWachowski

    Die Anzahl Threads der CPU spielt vermutlich ein wenig rein.

    Aber die Anzahl, der an den Prozessor angebundenen PCIe Lines dürfte in diesem Falle den Unterschied machen.

    Dein 9900K hat nur 16, die sich die GPUs teilen.

    Nicos CPU hat genug Lanes, so dass jede GPU mit 16 PCIe Lanes an der CPU angebunden ist.

    Da viele Daten auf die Karte und wieder runter kopiert werden, macht sich das bemerkbar.

    Führ mal einen Luxmark aus und schau, was dabei rauskommt.

  • „One more thing“ Apple Event 10. November

    Ich habe meinen M1 Mini seit Donnerstag letzter Woche und die Ergebnisse sind - wie ich finde zu erwarten war - gemischt.

    Die Benchmarks haben einen vermuten lassen, dass Single Thread Anwendungen schnell laufen und Multithread Anwendungen im Vergleich dazu langsam sind - es sei denn irgendeine Spezialfunktion auf dem M1 hilft - und dass die GPU besser als eine Intel GPU und schlechter als eine dedizierte Mittelklasse GPU sein würde.

    Erstmal merke ich keinen Unterschied zu meinem 10900K System. Wenn man mit der Stoppuhr misst ist der M1 hin und wieder schneller aber nicht spürbar. Ein paar Anwendungen für den 3D Druck und auch Cinema 4D haben Funktionen die von vielen Kernen profitieren und die sind auf dem M1 massiv langsamer (grob Faktor 2) als auf dem 10900K. Eine App verwendet die GPU in starkem Maße und auch da ist der M1 ganz weit weg vom Hackintosh mit einer Vega Frontier.

    Ich bin fasziniert von dem Potential und der Leistungsfähigkeit des M1 und Rosetta - denn machen wir uns nichts vor er zielt auf den i3 und i5 nicht auf den i9 mit dedizierter GPU.

    Selbst Apps unter Rosetta laufen flüssig mit ausgezeichneter Performance. Bisher habe ich nur zwei Apps gefunden, die Probleme zeigen. Aber Rosetta - ganz Dame - lässt die Apps nicht abstürzen sondern zeigt nur Fehler.

    16 GB genügen für das was ich tue und 4 Ports sind auch ausreichend.

    Bei meinen Anwendungen ersetzt der Mini noch nicht meinen Hack, aber wenn mein System ein i5 oder älterer i7 wäre, würde ich wohl wechseln.

  • „One more thing“ Apple Event 10. November

    ich bin etwas überrascht, was hier erwartet wird.

    Der M1 ist gegen den i3 oder einen niedrig getakteten i5 positioniert.

    Schließlich tauchen sie nicht im iMac oder im MacPro auf.


    Der M1 lässt keine echten Rückschlüsse auf die Performance des M2 oder wie auch immer die auf mehr Leistung getrimmte Version heißen wird, zu.


    Der schlechte Multithreatingwert liese sich ganz leicht anheben, indem man die 4 Efficiency Kerne durch 4 Performance Kerne ersetzen würde. Was bei Tischgeräten kein Problem sein sollte.


    Ja es wird interessant sein zu sehen wie der M1 in Benchmarks abschneidet, aber wichtiger ist, wie er sich im System verhält und wie im Vergleich zur alten Version des Rechners den er ersetzen soll abschneidet. Man beachte zu einem vergleichbaren Preis ersetzen soll.