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.
76 lines
3.0 KiB
Markdown
76 lines
3.0 KiB
Markdown
# 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 (`V<spannung>P<stufe>`) 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.
|