# Spike F — Taktfrequenzen über IOReport Untersucht am 10.08.2026 auf Mac17,9 (M5 Pro). **Ergebnis: teilweise gelöst, bewusst abgebrochen.** Der Datenzugang steht, die Umrechnung fehlt. ## Was funktioniert `libIOReport` ist ohne Entitlement nutzbar; alle benötigten Symbole sind vorhanden und über `dlsym` auflösbar: ``` IOReportCopyChannelsInGroup IOReportCreateSubscription IOReportCreateSamples IOReportCreateSamplesDelta IOReportStateGetCount IOReportStateGetResidency IOReportStateGetNameForIndex ``` Der Ablauf liefert verwertbare Daten: ``` Kanäle geholt: 127 (Gruppe "CPU Stats") Delta-Kanäle: 127 CPU Core Performance States/MCPU00 Zustände=17 IDLE:17345943 V0P14:3559973 V1P13:361673 V2P12:561938 V3P11:322658 … ``` Also je Kern (MCPU00 … MCPU14) die Verweilzeit in jeder Leistungsstufe seit der letzten Messung. Genau das, was man für einen gewichteten Mittelwert braucht. ## Woran es scheitert Die Frequenz zu einer Stufe steht nicht im Kanal. Sie muss aus den `voltage-states`-Tabellen im IODeviceTree kommen — und die Zuordnung geht nicht auf: | Tabelle | Einträge | Als Hz gelesen | |---|---|---| | `voltage-states8` | 26 | 732–2472 MHz — plausibel | | `voltage-states9`, `14`, `31` | 13 | 338–1620 MHz — plausibel, passt zur GPU | | `voltage-states5` | 20 | 0 MHz — Paare wie (50103, 635) | | `voltage-states22`, `23` | 15 | 0 MHz | Zwei Probleme übereinander: 1. **Die Stufenzahl passt nicht.** Der Kanal hat 17 Zustände, davon einer Leerlauf, also 16 Leistungsstufen. Keine Tabelle hat 16 Einträge. 2. **Die Einheiten sind uneinheitlich.** `voltage-states8` enthält echte Hertz. `voltage-states5` enthält Paare, deren erster Wert von 50103 abwärts läuft, während der zweite (635, 685, 710 …) nach Millivolt aussieht. Weder Hertz noch Kilohertz noch Megahertz ergeben daraus sinnvolle Taktraten. Die Zustandsnamen (`V0P14`, `V1P13`, `V2P12` …) kodieren offenbar Spannungs- und P-Zustands-Index getrennt. Ein sauberer Weg führte vermutlich über diese Namen statt über die Position im Kanal. ## Warum hier abgebrochen wurde Ab diesem Punkt ist es Reverse Engineering undokumentierter Firmware-Tabellen, deren Format sich zwischen Chip-Generationen ändert — genau die Sorte Code, die beim nächsten Mac still falsche Zahlen anzeigt statt zu scheitern. Der Aufwand steht nicht im Verhältnis zu einer Zusatzangabe im Popover, solange Phase 6 bis 9 noch offen sind. Die halbfertige Implementierung wurde entfernt statt auskommentiert: nicht verdrahteter Code, der `nil` zurückgibt, verrottet und täuscht später Vollständigkeit vor. Alles Nötige steht hier. ## Wenn es doch gebaut wird 1. Zustandsnamen zerlegen (`VP`) statt die Position zu benutzen. 2. Die Tabelle über den P-Index adressieren, nicht über die Einträgezahl. 3. Gegen `powermetrics --samplers cpu_power` gegenprüfen — das ist die einzige verlässliche Referenz. 4. Bei fehlender Zuordnung **nichts** anzeigen. Eine falsche Frequenz ist schlechter als keine.