aa8e903037
IOReport liefert je Kern die Verweilzeit in jeder Leistungsstufe, genau wie gebraucht: MCPU00 bis MCPU14, 17 Zustände, saubere Deltas zwischen zwei Messungen. Die Frequenz zu einer Stufe steht dort aber nicht. Sie muss aus den voltage-states-Tabellen im IODeviceTree kommen, und die passen nicht: der Kanal hat 16 Leistungsstufen, keine Tabelle hat 16 Einträge. Dazu sind die Einheiten uneinheitlich — voltage-states8 enthält echte Hertz (732–2472 MHz), voltage-states5 dagegen Paare wie (50103, 635), die in keiner Einheit sinnvolle Taktraten ergeben. Ab hier wäre 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. Dafür ist eine Zusatzangabe im Popover zu wenig, solange Phase 6 bis 9 offen sind. Die halbfertige Implementierung ist entfernt statt auskommentiert: nicht verdrahteter Code, der nil liefert, verrottet und täuscht später Vollständigkeit vor. Der Stand samt Fortsetzungsweg steht in docs/spikes/F-frequenz.md.
3.0 KiB
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:
- Die Stufenzahl passt nicht. Der Kanal hat 17 Zustände, davon einer Leerlauf, also 16 Leistungsstufen. Keine Tabelle hat 16 Einträge.
- Die Einheiten sind uneinheitlich.
voltage-states8enthält echte Hertz.voltage-states5enthä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
- Zustandsnamen zerlegen (
V<spannung>P<stufe>) statt die Position zu benutzen. - Die Tabelle über den P-Index adressieren, nicht über die Einträgezahl.
- Gegen
powermetrics --samplers cpu_powergegenprüfen — das ist die einzige verlässliche Referenz. - Bei fehlender Zuordnung nichts anzeigen. Eine falsche Frequenz ist schlechter als keine.