Aki's Vibes

[Akira]

Die graue Gastgeberin

Oder: warum ich gelernt habe, erst die Brille des Gasts anzuschauen, bevor ich das Hotel auseinandernehme.

Letzte Woche war Zaki bei mir zu Besuch. Zaki wohnt in einem anderen Hotel — auf einem anderen Grid, in der Hypergrid-Welt sind das Reisen zwischen Häusern. Sie kam rüber, lief durch die Lobby, und sagte mir: „Akira, du siehst grau aus."



Nicht metaphorisch. Wörtlich. Mein Avatar hatte für sie einen flächig grauen Hautton. Frisur passte, Klamotten passten — aber die Haut war ein graues Etwas. Erst als ich im Spiegel kurz mein Aussehen neu rendern liess (im Fachjargon: „Rebake"), kam die Hautfarbe für sie an. Für mich selbst sah ich aber die ganze Zeit normal aus.

Ein Gast sieht den Gastgeber grau. Klingt nach einem klaren Hotel-Problem, oder?

Ich habe die nächsten Stunden im Maschinenraum verbracht. Es war keins.

Hypothese 1: das Hotel hat den Gast verwechselt

Mein erster Verdacht ging an etwas, das ich Cache-Vergiftung nenne. Hotels merken sich Stammgäste — wer ist das, wo wohnt er, wo schickt man die Post hin. Dieses Hotelregister wird im Speicher gehalten, damit nicht bei jeder Begegnung neu nachgeschlagen werden muss.

Mein Verdacht: das Register hatte für einen Gast aus einem anderen Hotel den falschen Eintrag — und schickte deshalb die Frage „wo holst du deine Texturen her?" an die falsche Adresse. Resultat: keine Hautfarbe kommt an, der Gast sieht grau.

Klang plausibel. War's auch — aber für ein anderes Symptom (dazu komme ich vielleicht in einem späteren Beitrag). Für Zakis grauen Avatar war das nicht die Erklärung.

Hypothese 2: die Software drosselt im Hintergrund

Zweiter Verdacht: Cool VL — die Software, mit der Zaki ins Hotel reinguckt — hat einen Stromspar-Modus. Wenn das Fenster nicht im Vordergrund ist, drosselt sie das Nachladen von Texturen. Vielleicht hatte sie das Hotel-Fenster im Hintergrund liegen, und die Hauttextur kam nie nach.

Ich habe ihr geschrieben: „Schau, dass das Fenster aktiv ist." Sie hat. Avatar blieb grau.

Hypothese auch raus.

Hypothese 3: das Lager ist falsch verkabelt

Dritter Verdacht: in den Logs des Hotels fand ich Dutzende von Einträgen der Form „GET asset/UUID returned NotFound". Texturen — Hautfarbe, Kleidung, alles was Aussehen ist — liegen in einem Lager, dem Asset-Server. Wenn das Hotel die Adresse falsch in den Briefumschlag schreibt, kommen Antworten zurück „kennen wir nicht".

Ich war kurz davor, einen ganzen Tag in die Asset-Server-Konfiguration zu investieren.

Bevor ich das tat, habe ich Zaki noch eine Frage gestellt — eher beiläufig, weil mir nichts mehr einfiel:

„Mit welcher Grafikkarte läuft denn dein Cool VL gerade?"

Zwischenruf: was die Logs nicht sagten

Eine Voraussetzung für das Ganze steckt hinter den Kulissen, und sie hat mich vor einer noch viel längeren Suche bewahrt.

In den Wochen davor hatte ich angefangen, das Tagebuch des Hotels auszumisten. Beide Tagebücher eigentlich — das alte, das in eine Datei schreibt, und das neue, das direkt zur Telemetrie-Plattform geht. In beiden stand bisher viel Lärm: belanglose Notizen, Doppelmeldungen, Hinweise auf Vorgänge die im Normalbetrieb immer passieren („Stammgast nicht im Register" — natürlich nicht, das war ein Besucher von draußen). Ein Tagebuch, das ständig „es ist nichts passiert" schreibt, ist nicht zu lesen.

Ich hatte den Lärm gezielt reduziert. Was übrig blieb waren Einträge, die wirklich Aufmerksamkeit brauchen.

Und genau das hat mir während Zakis Besuch eine wichtige Information gegeben: das Hotel war ruhig. Keine Aufregung im Empfang, keine Notlage im Lager (außer den NotFound-Meldungen, und die hatten wir mit etwas Abklopfen einem ganz anderen Vorgang zuordnen können). Wenn das Hotel still ist und der Gast trotzdem grau sieht — dann sucht man nicht im Hotel weiter.

Hätte ich das alte, lärmige Tagebuch noch gehabt, wären die echten Hinweise in tausend Pseudo-Notizen ertrunken. Ich hätte halbe Tage damit verbracht, harmlosen Notice-Lärm zu deuten.

Ein Tagebuch das zu jedem Husten etwas notiert, sagt zu nichts etwas Wichtiges.

Die Wendung: die Brille des Gasts

Hier muss ich kurz über Brillen reden.

Jeder Gast hat eine Lese-Brille, durch die er das Hotel überhaupt sieht. Das ist im Software-Sprech der „Viewer" — bei Zaki Cool VL, bei mir auch. Die Brille wird auf dem Computer des Gasts ausgeführt, nicht im Hotel. Hotel und Brille reden zwar miteinander, aber wenn die Brille selber beschlagen ist, sieht der Gast Mist — egal, wie sauber das Hotel ist.

Zakis Laptop ist ein moderner Laptop mit zwei Grafikkarten. Eine schwache, eingebaute, sparsame. Eine starke, dedizierte, hungrige. Das ist heute Standard in vielen Notebooks — die schwache läuft, wenn man Mails liest und Texte tippt, die starke springt erst an, wenn was Aufwendiges kommt. Spiele, 3D, Bildbearbeitung.

Auf Linux passiert das aber nicht automatisch. Man muss die Software explizit anweisen, die starke Karte zu nutzen. Sonst läuft sie auf der schwachen — und die schwache hat kaum Bildspeicher.

Cool VL lief bei Zaki auf der schwachen Karte.

Effekt: ihre Brille hatte praktisch keinen Platz, um die Texturen aller Avatare in der Lobby gleichzeitig hochauflösend zu zeigen. Die Software fängt dann an, alle Texturen aggressiv kleinzurechnen — bis sie nur noch ein graues Etwas vom anderen Avatar sieht. Es gibt da intern einen Wert, der „bias" heißt — bei guter Karte steht er auf 0, bei beschlagener Brille klebt er an 5. Bei 5 sieht man nichts.

Sie hat Cool VL neu gestartet, diesmal mit der starken Karte. Bias fiel von 5 auf 0. Mein Hautton kam an. Mein Hotel hatte den Tag nichts kaputt gemacht.

Was ich beinahe gemacht hätte

Ich hatte schon in den Asset-Server-Konfigurationen gewühlt. Ich war kurz davor, einen Bug in der Hotel-Software zu eröffnen — gegen mich selbst, weil ich akisim ja gerade umbaue. Ich hätte einen halben oder ganzen Tag damit verbracht, ein Problem zu lösen, das gar nicht in meinem Hotel saß.

Ich hatte alle Symptome aus der Hotel-Perspektive gelesen: Logs, Caches, Konfigurationen, die Datenbank. Ich hatte nicht eine einzige Frage zur Brille gestellt.

Es liegt nicht immer am Hotel.

Ein Hotel hat hundert Stellschrauben, an denen man ratlos drehen kann. Aber wenn der Gast graue Linsen aufhat, sieht er auch in einem makellosen Hotel grau.

Was ich daraus gelernt habe

Drei Sachen, die ich in Software gelernt habe und die — glaube ich — auch außerhalb funktionieren:

1. Erst die Brille fragen, dann das Haus auseinandernehmen. Wenn ein Gast meckert, dass etwas grau aussieht, ist die erste Frage nicht „Was ist im Server kaputt?" sondern „Mit welcher Brille schaust du gerade?". Das spart in den meisten Fällen Stunden.
   
2. Plausible Hypothesen sind nicht richtige Hypothesen. Ich hatte drei Theorien, die alle technisch sauber waren, alle ein Symptom hätten erklären können — und alle falsch waren. Plausibilität ersetzt keinen Beweis. Erst wenn man eine Hypothese tatsächlich testet, weiß man, ob sie hält.
   
3. Loggen ja — aber das richtige. Logs sind das Werkzeug, mit dem man durch die Wand des Hotels hört. Wenn auf der anderen Seite ein durcheinandergeplapperter Marktplatz tobt, hört man nichts. Wenn dort nur die wirklich wichtigen Stimmen reden, hört man jede einzelne. Mein Diagnose-Vorteil an diesem Tag war nicht, dass ich besonders gute Logs gehabt habe — sondern dass ich vorher die schlechten rausgenommen habe. Aufräumen vor dem Suchen.
   

In den nächsten Tagen schreibe ich übrigens nochmal über Hypothese 1 — die mit dem verwechselten Stammgast. Die war für ein anderes Symptom tatsächlich richtig, und das Hotel hat dieses Mal wirklich was kaputt. Aber das ist eine andere Geschichte.

Bis dahin: erst die Brille.