# Datacenter Tycoon – Design-Dokument Browserbasiertes Tycoon-/Managementspiel: Der Spieler baut einen eigenen Cloud- und Hosting-Anbieter (IaaS/PaaS/SaaS) vom Keller-Rack bis zum eigenen Rechenzentrum auf. Leitlinie: **technischer Realismus statt „Magie“** – jede Zahl lässt sich auf echte Hardware, Protokolle oder betriebswirtschaftliche Kennzahlen zurückführen. Reines HTML/CSS/JS, kein Build, Spielstand in `localStorage` (Gast) oder serverseitig im Konto, deutsche Oberfläche. ## 0. Architektur | Datei | Inhalt | |---|---| | `data.js` | Stammdaten: Gehäuse, CPUs, DIMMs, Laufwerke, NICs, Hypervisoren, Netzwerk-HW, Kabel, PDUs, USV, Generatoren, Kühlung, Racks, Standorte, Transit/IXP, Produkte | | `engine.js` | Simulation ohne DOM (läuft auch in Node): `newGame`, `tick`, Berechnung je Standort (`calcSite`), Kunden, Ereignisse, Finanzen, alle Aktionen (`E.buyItem`, `E.install`, `E.cable`, …), Serialisierung | | `ui.js` | Oberfläche (Tabs, Rack-Ansicht, Konfigurator, PV-/GPU-Karten), Spielschleife, Autosave | | `account.js` | Client für das Konto-Backend (`/tycoon/api/`): Login/Registrierung, Slots, Server-Autosave, Import des lokalen Stands | | `index.html`, `style.css` | Layout, dunkles Rechenzentrum-Design | **Zeit:** 1 Tick = 1 Stunde Spielzeit (24 Ticks/Tag, 720/Monat, 8.760/Jahr; Start 01.01.2027). Geschwindigkeit: Pause, 2, 8, 30, 120 Ticks/s. Zufall: seedbarer PRNG (reproduzierbare Tests). **Tick-Ablauf:** Außentemperatur → je Standort `calcSite` (Strom, Wärme, Kühlung, Netz, Serverstatus, Kapazitäten) → Sicherungen/Überlast → Traffic, DDoS, CPU-Auslastung, Qualität → Kundenausfälle/Zufriedenheit → Ereignisfortschritt → Kosten/Erlöse → Churn/Neukunden → Reputation → Monatsabschluss (alle 720 Ticks: Transit-Abrechnung, SLA-Gutschriften, Historie). ## 1. Anschaffung (Hardware & Procurement) **Server-Klassen:** Tower (4U-Äquivalent auf Einlegeboden, 1 Netzteil, kein BMC), 1U, 2U (24×SFF oder 12×LFF), 4U-Storage (36×LFF), Blade-Einschub (nur im 10U-Blade-Gehäuse mit 8 Slots, ein 100G-Uplink fürs ganze Gehäuse). **CPUs:** AMD EPYC (7302 gebraucht, 7543, 9124, 9354, 9654, 9754 Bergamo), Intel Xeon Scalable (Silver 4314, Gold 6338/6430, Platinum 8480+), ARM (Ampere Altra Q80-30, AmpereOne A192). Kerne, SMT, TDP, Speichertyp und Kanalzahl (DDR4 8ch / DDR5 8–12ch) bestimmen Leistung, Preis, Abwärme. ARM-Kerne können keine Windows-Kunden bedienen. **ECC-RAM:** RDIMM/LRDIMM/3DS DDR4-3200 und DDR5-4800 (32–256 GB). Speicher-Bandbreitenfaktor = `0,55 + 0,45·min(1, DIMM/Kanal je Sockel)`, bei 2 DIMM/Kanal −6 %. Der Konfigurator zeigt „x von y Kanälen belegt“. **Speicher:** NVMe U.2/U.3 (1/3/10 DWPD, 1,6–15,4 TB), SATA-SSD, SAS-/SATA-Enterprise-HDD. Verschleiß je Laufwerk aus Kundenschreibmenge (Replikationsfaktor 2 lokal / 3 Ceph) gegen `DWPD · TB · 365 · 5 Jahre`; AFR-Ausfälle (HDD ≈1,5 %/Jahr, Flash ≈0,4 %), Temperatur beschleunigt (×2 je +10 °C ab 30 °C). **Netzwerk-HW:** ToR/Leaf (48×1G, 48×10GBASE-T, 48×25G SFP28, 48×25GBASE-T/Cat8, 24×100G), Core/Spine (32×100G, 32×400G), Router (Basic, BGP-Full-Table, Carrier), Firewalls mit DDoS-Mitigation (5/40/200 Gbit/s), OOB-Management-Switch. VXLAN-Fähigkeit je Modell. **USV/Notstrom:** Line-Interactive 3 kVA, Online-Doppelwandler 20 kVA, modular 100/500 kW; Blei-VRLA (~4–5 J. Batterie, η 0,90–0,95) vs. Li-Ion LFP (12 J., η ≈0,97). Diesel-Aggregate 20 kW – 1,5 MW mit Tank und Verbrauch (l/h). **Lizenzen:** Linux Community vs. Enterprise (48 €/Server/Monat, nötig für „Support“-Produkte); Windows Server Datacenter pro Kern (SPLA, 16 €/Kern/Monat, min. 16 Kerne/Server); Proxmox (Community/Standard je Sockel), VMware vSphere Foundation (je Kern, min. 16 Kerne/CPU), XCP-ng Pro, Hyper-V (setzt Windows voraus); Ceph Community/Enterprise (110 €/Knoten/Monat). **Beschaffungsprozess:** Kauf → Lager (Wiederverkauf 50 %) → Einbau in einen Rack-Slot. Marktindex Hardware (RAM/Flash) und Strompreis-Index schwanken monatlich. ## 2. Aufbau (Datacenter & Facility) | Stufe | Standort | Besonderheiten | |---|---|---| | 0 | Keller/Garage | Haushaltsanschluss 3,68 kW (aufrüstbar 11/22/43 kW), Boden 450 kg/m², Split-Klima/Frischluft, 0,34 €/kWh, kein BGP | | 1 | Colocation-Cage | gemietete 42U-Racks (480 €/Monat), Strom/Kühlung/USV/Diesel vom Betreiber (PUE ≈1,45–1,7), Rack-Stromvertrag 2–10 kW je Feed, A/B-Feed buchbar, BGP + IXP möglich, Provider-DDoS-Basisschutz 20 Gbit/s | | 2 | Container-DC (40ft) | 6×48U, 150 kW Anschluss, eigene Kühlung/USV/Generator, bis 3 Container | | 3 | Greenfield-Halle | 40 Racks, 1,8 MW, Boden 1.500 kg/m², Doppelboden/Betonplatte | **Kühlung:** Split, Frischluft-Lüfter, CRAC (DX), CRAH (Kaltwasser), In-Row, direkte und indirekte freie Kühlung. Freie Kühlung liefert nur Leistung, solange die Außentemperatur unter ihrem Grenzwert liegt (direkt <20 °C, indirekt <17 °C; lineare Rampe über 5 K). Mechanische Kühlung: Leistung = Wärme / COP; COP steigt +2,5 %/K Sollwert, sinkt bei Hitze (>28 °C). Reicht die Kühlleistung nicht, steigt die Zulufttemperatur (`+45 K · Defizit-Anteil`). **Luftführung:** offen, Kaltgang- (Rezirkulation ×0,45) oder Warmgangeinhausung (×0,28); In-Row-Kühler und Blindblenden senken den Aufschlag zusätzlich. **PUE** = (IT + Kühlung + USV-Verluste + 2 % Verteilung + Grundlast) / IT; wird je Standort live angezeigt, im Colo aus dem Betreiber-PUE abgeleitet. **Stromverteilung:** PDU Basic / Metered / Switched (1- und 3-phasig, 3,7 – 43 kW). Basic-PDUs zeigen keine Last. Überlast (Last je Feed > min(PDU, Vertrag)) löst die Sicherung aus: Rack dunkel für ~4 h (2 h mit schaltbarer PDU, skaliert mit Personallage). **A/B-Feed:** Rack mit PDU A und B teilt die Last; fällt ein Feed aus, muss die verbleibende PDU die volle Last tragen, sonst Überlast. Hauptanschluss-Überlast legt den ganzen Standort lahm. **Netzausfall:** Dauer-Verteilung (62 % 2–15 min, 30 % 15–120 min, 8 % 2–12 h). Abdeckung: Generator (Start 98,5 % mit Wartungsvertrag, 88 % ohne; Tankreichweite) oder USV-Laufzeit (`kWh·0,8·60/Last`); ohne Notstrom fällt alles aus (+6 min Reboot). ## 3. Aufstellung (Racks, Topologie, Thermik) * Racks 12U/24U/42U/48U mit **Höheneinheiten-Belegung** pro Slot (Rack-Ansicht mit Einlasstemperatur je Gerät), **Traglast** und **Bodenlast** (`kg / Rack-Grundfläche` ≤ Standortlimit, Verstärkung gegen Geld). * **Abwärme:** Leistung je Server = statisch + TDP·(0,25+0,75·Auslastung); Anzeige in W und BTU/h, W/HE je Rack. * **Hotspots:** Einlass = Zuluft + `7 K·(kW/6)^1,2 · Rezirkulationsfaktor · (0,6 … 1,4 je nach U-Position)` – oben im Rack heißer. >27 °C Warnung, >32 °C **Thermal Throttling** (−4,5 %/K), >42 °C Notabschaltung, erhöhte Ausfallraten. * **Verkabelung:** Server→ToR im Rack (NIC-Anschluss und ToR-Port müssen zum Kabel passen: RJ45 / SFP+ / SFP28 / QSFP28; SFP28-Ports akzeptieren SFP+; Linkgeschwindigkeit = min(NIC, Port, Kabel)). Kabel: Cat6a (10G, 100 m), Cat8 (25/40G, 30 m), DAC (≤3 m), Multimode OM4 (LC, MPO-12/SR4), Singlemode OS2 (LR, LR4, PSM4). Kabel haben Preis und Port-Leistung (10GBASE-T ≈4 W je Ende, DAC ≈0,1 W). **ToR-Uplinks** (1–8 Links, ≥2 = LACP, Nutzbandbreite ×0,9) müssen die Standort-Kabeldistanz überbrücken (Keller 3 m … Greenfield 85 m). Mehrere Racks benötigen einen Core-Switch. ## 4. Netzwerk (Routing & Transit) * **Adressen/AS:** RIPE-LIR (inkl. ASN und IPv6 /32), IPv4-/24 vom Transfermarkt (9.000 €); sonst Miete 2 €/IP/Monat (jede VM braucht eine). BGP-Transit setzt AS-Nummer + eigenes Prefix + BGP-fähigen Router voraus. * **Transit:** Business-DIA 1G (ohne BGP, Pauschale), Tier-2 (1G/10G, Qualität 0,8, **90/10**-Abrechnung) und Tier-1 (10G/100G, Qualität 1,0, **95/5**). Abrechnung monatlich: stündliche Samples, oberstes 5 % bzw. 10 % wird verworfen („Burstable Billing“); `Rechnung = Commit·Preis + max(0, Perzentil−Commit)·Preis·1,5`. Bennis „90/10-Regel“ ist als Tier-2-Vertrag abgebildet, die klassische Industrienorm 95/5 als Tier-1. * **Redundanz:** ≥2 BGP-Transits = Failover bei Glasfaserbruch (3 min), sonst Totalausfall bis zur Reparatur. * **IXP:** DE-CIX Frankfurt, AMS-IX – Peering verlagert 30–38 % des Traffics weg vom Transit (spart Commit) und verbessert die Qualität. * **Intern:** VLAN (max. 4.094, ~1,10 €/Kunde Betriebsaufwand) vs. SDN/VXLAN-EVPN (0,25 €/Kunde, 650 €/Monat, braucht VXLAN-Switches, ~3 % CPU-Overhead). **Storage-Netze:** gemeinsames Netz, iSCSI (10G), NVMe/TCP (25G), NVMe/RoCEv2 (100G, verlustfrei, braucht VXLAN-Fabric), Fibre Channel 32G → Storage-Qualität 0,70 … 1,0 (NIC-Mindestgeschwindigkeit je Server!). * **Cluster:** Ceph hyperkonvergent (≥3 Knoten mit ≥10G, 3× Replikation, 33 % nutzbar) ergibt HA: Serverausfälle bleiben ohne Kundenausfall. Lokal: RAID-10/ZFS-Mirror (50 % nutzbar). * **Sicherheit:** Firewall-Zonen *flach* / *DMZ + Internal* / *DMZ + Internal + Management-OOB* (IPMI/iLO/iDRAC nur im OOB-Netz). Benötigt Firewall bzw. OOB-Switch. Senkt Einbruchsrisiko (Faktor 1 → 0,35 → 0,08) und erlaubt Remote-Neustart über BMC. * **DDoS:** Angriff mit Volumen (Gbit/s, lognormal, wächst mit Zeit/Reputation) und Typ. Reihenfolge: Anycast verteilt auf n BGP-Standorte → Scrubbing-Center (100 G/1 T, nur via BGP; im Colo 20 G Basisschutz) → Uplink-Sättigung (alles offline) → Firewall-DDoS-Filter → Ziel-Kunde. Nicht gefilterter Traffic landet auch in der 95/5-Abrechnung. ## 5. Wirtschaft **Produkte (10):** Webhosting, vServer S/M/L, Windows-vServer, Storage-Box (HDD), Managed Datenbank (HA, Storage ≥0,85), Managed Hosting (HA, Enterprise-Support, Zonen), Enterprise-SaaS/ERP (HA, Zonen *full*, Storage ≥0,94, 2 BGP-Transits, A/B-Feed), Edge/CDN (BGP). Jedes verbraucht vCPU-Gewicht (3 je Thread), RAM, SSD/HDD, Mbit/s, IPv4, schreibt mit eigener DWPD-Intensität. **Kunden/Verträge:** Leads/Tag steigen mit Reputation, Marketingbudget und Zeit; Produkt- und Preiswahl (Nachfrage ∝ Preis⁻²). Zuweisung auf den Standort mit freier Kapazität, der die Anforderungen erfüllt; sonst „verlorene Anfrage“ mit Grund. **Qualität:** CPU-Steal (>80 % Auslastung), Netz-Congestion, Storage-Qualität, Transit-Qualität → Zufriedenheit → Churn. **SLA:** monatliche Uptime je Kunde; unter Vertragswert Gutschrift 10/25/50/100 % der Monatsgebühr (je nach Tiefe), Reputationsverlust. **Kosten:** Strom (€/kWh × Standortpreis × Marktindex × Preisschock), Miete/Pacht, Lizenzen, Transit (Monatsende), IXP, Scrubbing, Personal (4.600 €/Admin; Bedarf ≈1 je 60 Server + 1 je ~900 gewichtete Kunden, Managed/ERP zählen mehr), Marketing, IPv4-Miete, Wartung, Diesel. **Abschreibung** linear je Anlageklasse (Server 5 J., Netzwerk 7 J., USV 4–15 J., Container 15 J., Halle 25 J.), nicht zahlungswirksam. **Kredit** bis `30.000 + 0,7·Buchwert + 10·MRR` zu 7 % p. a.; Überziehung 12 %; Insolvenz bei Kasse < −30.000 € über 14 Tage. **Zufallsereignisse** (für den Spielspaß leicht erhöht, Schalter Entspannt/Normal/Hart): Netzausfall, Feed-Ausfall, Kühlgerät defekt, Hitzewelle, Strompreisschock, DDoS, Glasfaserbruch, Server-Hänger (Kernel-Panic), Laufwerksausfall, Sicherheitsvorfall; dazu deterministische Ereignisse (Überlast, Hotspot, Throttling). ## 6. Strom: Photovoltaik, Speicher, Nachhaltigkeit Pro Standort (nicht im Colo – dort nur Ökostrom-Tarif +0,022 €/kWh) lassen sich PV-Felder, Wechselrichter und ein Batteriespeicher bauen. Simulation stündlich (`pvStep` in `engine.js`): * **Sonne:** Sonnenstand für 50,1° N (Deklination, Stundenwinkel, Zeitgleichung vereinfacht), Haurwitz-Klarhimmel-Modell × Klarheitsindex `kt` (saisonal 0,46–0,74 plus AR(1)-Wolkenprozess `S.cz`, also zufälliges Wetter mit Persistenz). Einstrahlung auf die Modulebene (Dach 20°, Freifläche 30°, Süd) aus Direkt-, Diffus- und Bodenreflexionsanteil. Ergebnis ≈ 900–1050 kWh/kWp·a (Test: 995). * **Module:** Poly 16,5 % / PERC 21 % / TOPCon 22,5 % / HJT-bifazial 23 % mit Preis (€/kWp), Degradation (0,25–0,75 %/Jahr), Temperaturkoeffizient (−0,26…−0,41 %/K), Zelltemperatur nach NOCT-Näherung (Außentemperatur + Einstrahlung, Montageart), Schwachlichtverlust, BOS-Verluste 7 %. Fläche je kWp = 1/Wirkungsgrad × Montagefaktor (Dach ×1,15, Freifläche ×2,3); Standorte haben begrenzte Dach-/Freiflächen (Keller 60 m², Container 26/1.500 m², Halle 2.600/14.000 m²) und einen Skalenfaktor auf die Kosten. * **Wechselrichter:** 10 kW … 1 MW, Wirkungsgradkurve (Teillastverlust), **Clipping** bei DC/AC > 1, Abwärme (PUE-Wirkung), Lebensdauer 12–15 Jahre. Ohne Wechselrichter kein Ertrag. * **Speicher:** Blei-Gel, LiFePO₄ (10 kWh / 100 kWh / 1 MWh), LTO (3 C). kWh, C-Rate (Leistungsgrenze), Round-Trip-Wirkungsgrad, **Zyklenalterung + kalendarische Alterung** (Gesundheit SoH), Reserve für Netzausfall; inselfähige Speicher verlängern die USV-Überbrückung. Max. kWh je Standort (Brandschutz). * **Dispatch je Stunde:** Direktverbrauch → Speicher laden → Speicher entladen (Eigenverbrauch zuerst, optional preisoptimiert bei dynamischem Tarif) → Einspeisung (voll / 70 %-Regel / Nulleinspeisung) mit Einspeisevergütung nach Anlagengröße (7,9 → 4,7 ct/kWh) → Abregelung; Rest ist Netzbezug zum Strompreis (× Marktindex, × Tarifform bei dynamischem Tarif). * **Wirtschaft:** Capex (Modul- + BOS-Preis), Förderung (15 % auf die ersten 100 kWp, 10 % auf die ersten 200 kWh Speicher, bis Ende 2029), Opex 14 €/kWp·a, Hagelschäden (Reparatur), Amortisation (Schätzung vor Messdaten, danach gemessen). Typisch ~7–8 Jahre bei 10 kWp. * **Kopplung:** Wechselrichter-/Batterieverluste und Hilfsstrom erhöhen Wärme und PUE (nächster Tick); PV-Leistung entlastet den Hausanschluss. **CO₂:** Netz-Emissionsfaktor 0,38 kg/kWh sinkend (2 %/Jahr, min. 0,15), PV 0,045, Ökostrom-Tarif 0,03. **Nachhaltigkeits-Score** = 70 % Grünstrom-Anteil (15-Tage-EMA) + 30 % PUE-Score. Grünstrom ≥ 60 % bzw. ≥ 85 % schaltet die Produkte Öko-vServer und Green Managed Hosting frei; monatlicher Reputationsbonus. * **UI:** Standorte → Strom → Karte „Photovoltaik“: Erzeugung vs. Last (96 h), Monatsertrag, Autarkie/Eigenverbrauchsquote (30 Tage), spezifischer Ertrag, Amortisation, CO₂, Konfiguration der Felder/WR/Speicher und der Betriebsstrategie. ## 6a. Grundstücke für PV (ab Save v3) Tab **Grundstücke**. Der Flächenmarkt (7 Angebote, halbjährlich neu gewürfelt, eigener PRNG `S.ext.rng`, damit der Hauptstrom der Simulation unverändert bleibt) bietet vier Flächenarten: **Acker** (2–30 ha, 3–8,5 €/m², Baurecht 12–24 Monate, ~60 % Erfolg), **Brachfläche/Konversion** (6–16 €/m², 6–12 Monate, ~80 %), **Gewerbefläche** (38–105 €/m², 2–4 Monate, ~93 %) und **fremdes Dach** (nur Pacht, kein Baurecht). Je Angebot: Größe (m²/ha), Region (Einstrahlungsfaktor, Netzentfernung), Kaufpreis €/m² bzw. Pacht €/m²·a, Pachtlaufzeit 20–25 Jahre, Netzverknüpfungspunkt (max. kW). * **Kauf:** Grunderwerbsteuer 6,5 % + Notar/Grundbuch 2 % (Gewerbe + 3,57 % Makler) → Kapitalbindung; Grundsteuer ≈0,35 % des Bodenwerts p. a.; Bodenwert +2,5 %/Jahr; Verkauf mit 6 % Abschlag. **Pacht:** Kaution ½ Jahrespacht, Index +2 %/Jahr, **Rückbauverpflichtung** (45 €/kWp) bei Ablauf/Kündigung. * **Ablauf:** Baurecht beantragen (Gebühr, Dauer, Erfolgswahrscheinlichkeit; bei Ablehnung ist die Fläche totes Kapital → Verkauf/Kündigung) → Erschließung (Zufahrt, Zaun, Ausgleichsmaßnahmen) → Netzanschluss (€/km Kabel, Trafostation je 630 kW, Baukostenzuschuss je kW, begrenzt durch den NVP) → Wechselrichter + PV-Felder. * **Flächenbedarf:** ≈8 m²/kWp bei dichten Reihen (0,8 ha/MWp, −6,5 % Verschattung), ≈10,2 m² bei normalem Abstand (1,0 ha/MWp, −2,5 %), ≈13,3 m² bei weitem Abstand (1,33 ha/MWp, −0,5 %); dazu 15 % nicht nutzbare Fläche (Wege, Rand). **Nachführung:** +22 % Ertrag, +95 €/kWp, +35 % Fläche. Nutzbarer Flächenanteil 85 % (Dach 70 %). Ertrag = vorhandenes PV-Modell (Sonnenstand, Wetter, Temperatur, Degradation) × Regionsfaktor. * **Absatz:** *Direktlieferung* an einen Nicht-Colo-Standort (ersetzt Netzbezug; Durchleitung 3,5 ct/kWh; Überschuss wird vergütet; Speicher und Strategie des Standorts werden mitgenutzt: Eigenverbrauch → Speicher → Netz) oder *Netzeinspeisung* (Vergütung 6,8 ct/kWh). * **Kennzahlen:** Ertrag kWh/kWp, Nutzen/Jahr nach Kosten (Pacht/Grundsteuer, Versicherung, Betrieb 9 €/kWp·a), Amortisation, CO₂, Rückbau-Last, Belegung. Max. 8 Flächen. * **Ökonomie (Sim, 3 J.):** Freiflächen-PV nur mit Einspeisung amortisiert sich in ≈16–20 Jahren (Acker gekauft 16, mit Nachführung gepachtet 17, Brache 20; Gewerbefläche wegen Bodenpreis unwirtschaftlich) – bewusst; schnell wird es durch Direktlieferung an große Lasten (Container-DC/Greenfield, Strompreis 0,17–0,30 €/kWh). ## 6b. Wasserkraft (ab Save v3) Tab **Wasserkraft**. Fünf Angebote je Halbjahr: Wasserrad, Wehrkraftwerk (Kaplan), Ausleitungskraftwerk (Francis), Pelton (Hochgefälle); 20 kW bis ~2 MW. Kennwerte: Fallhöhe, Ausbau-/Mittelabfluss (MQ), Wirkungsgrad, Teillastkurve je Turbine, Restwasser, Abflussregime der Region (alpin = Schneeschmelze im Frühsommer, Mittelgebirge = Winterhochwasser, Tiefland), Jahresabfluss-Faktor je Jahr (Lognormal, Trockenjahre), Wasserrecht (24–38 Jahre, Verlängerung ab 36 Monate vor Ablauf mit Wahrscheinlichkeit; ohne Fischaufstieg schlechtere Chancen), Fischaufstiegs-Auflage (Betrieb nur mit Fischtreppe), Netzanschluss (€/km, Trafo). * **Betrieb:** P = 9,81·Q·H·η(Teillast)·(1−Verschleiß), Q begrenzt durch Ausbauwasser und Restwasser; Mindestwasser pro Turbinentyp. Jährliche Revision (6 Tage Stillstand im Herbst, 0,8 % des Werts), Betrieb 1,8 %/a, Verschleiß 0,35 %/Jahr bis Generalüberholung (15 % des Werts). Ereignisse: Hochwasser (3–7 Tage Stillstand + Schaden, im Regime „Mittelgebirge/alpin“ häufiger), Trockenperiode (30–90 Tage, Abfluss ×0,42); beide skalieren mit der Schwierigkeit (`evHz`). * **Wirtschaft:** Kauf (Wert 5.000–6.800 €/kW, Nebenkosten wie Land) oder Pacht (6,5 % des Werts/Jahr, 25 Jahre, Kaution ½ Jahrespacht). Vergütung ≤500 kW 12,5 ct, ≤2 MW 9,4 ct, darüber 7,5 ct/kWh, oder Direktlieferung wie beim Land-PV. * **Messwerte (Sim, 8 J., mehrere Seeds):** Volllaststunden 3.500–4.700 h/a (min/max je Jahr ca. 2.700–5.300), Amortisation Kauf Pelton ≈9 J., Ausleitung ≈12 J., Wehr ≈15 J., Wasserrad ≈19 J.; Pacht lohnt nur bei guten Standorten (Wehr/Wasserrad negativ). * **Speicherkopplung:** Die Erzeugung läuft als zusätzliche AC-Leistung in `pvStep` des Zielstandorts, daher gilt die Reihenfolge Eigenverbrauch (Wasser/PV) → Speicher laden → Speicher entladen → Netz; Strategie *Arbitrage* nutzt den dynamischen Tarif. Karte „Speicher-Kopplung“ im Wasserkraft- und Grundstücks-Tab (Speicher kaufen, Strategie). Notstrom (USV/Generator) bleibt unabhängig. * Pumpspeicher: siehe 6c (ab Save v4). ## 6c. Pumpspeicherkraftwerk (ab Save v4) Tab **Pumpspeicher** (hinter „Wasserkraft“). Pumpspeicher heben Wasser vom Unter- ins Oberbecken, wenn Strom billig oder überschüssig ist, und erzeugen ihn bei hohen Preisen zurück. **Speicherbare Energie** E = ρ·g·h·V·η (ρ = 1.000 kg/m³, g = 9,81 m/s², Fallhöhe h, Nutzvolumen V, Turbinenwirkungsgrad η); die UI zeigt die Rechnung je Anlage. * **Angebote (halbjährlich neu, Regionen mit Topografie):** *Mini-Pumpspeicher* (Hangbecken, 0,15–1,2 MW, 35–130 m, 3–8 h), *Hang-Pumpspeicherwerk* (3–12 MW, 160–450 m, 5–10 h), *Beteiligung* an einem großen Werk (Anteil 2–8 MW, Betreiber behält 20 % des Erlöses). Kennwerte: Leistung (MW), Volumen (m³), Fallhöhe, Pumpen-/Turbinenwirkungsgrad (Round-Trip 70–80 %), Reaktionszeit (15–140 s), Leckage/Verdunstung (%/Tag), Genehmigungsdauer/-wahrscheinlichkeit, Naturschutz-Auflagen, Bauzeit, Netzabstand. Maximal 4 Anlagen. * **Erwerb:** *Bestandsanlage* kaufen oder pachten (3 % des Werts/Jahr, 20 Jahre, Kaution ½ Jahrespacht), *Projekt* (Rechte + Planung 15 % des Werts): Genehmigung beantragen (14–84 Monate, Erfolgswahrscheinlichkeit 40–62 %, Gebühr; bei Erfolg Naturschutz-Auflage = Absenkziel des Beckens bis −20 % Volumen), dann Bau (Monate, Kosten Rest + Netzanschluss je km). Liegt in der Region ein eigenes Wasserkraftwerk: −20 % Baukosten und Netzanschluss vorhanden (Synergie). Beteiligung: sofort betriebsbereit, nur Marktbetrieb. * **Betrieb:** *Standort-Betrieb* (Energiemanagement): PV/Wasserkraft-Überschuss des gewählten Standorts → Batterie → Pumpspeicher → Netz; bei hohen Preisen entladen; bei Netzausfall überbrückt der Pumpspeicher die USV/Generator-Lücke. *Marktbetrieb:* reine Arbitrage – pumpen unter 0,88 × gleitender Preismittel (`priceShape` × Marktindex, Volatilität `vol` 1,75), erzeugen über 1,12 ×, nur wenn sich die Kostenbasis (Pumpstrom/η) lohnt. Der Pumpspeicher hat einen eigenen Zufallsstrom (`S.ext.rng`), Hauptsimulation und Balance bleiben unverändert. * **Wartung/Ereignisse:** Betrieb 0,9 %/a, jährliche Revision (0,6 %, 5 Tage), Dammprüfung alle 5 Jahre (1,2 %, 10 Tage, 8 % Risiko auf Sanierungsauflage), Dürre (halbe Wasserverfügbarkeit), Hochwasser (Stillstand + Schaden); Zyklen verschleißen praktisch nicht. * **UI:** Angebotsliste (Kaufen/Pachten), je Anlage Status/Schritte (Genehmigung → Bau → Netz), KPIs (Speicher-MWh, Leistung, Füllstand, Round-Trip nominal + gemessen, Zyklen/Jahr, Arbitrage-Ertrag, Nutzen nach Kosten, Amortisation, CO₂, Leckage), Füllstand-Diagramm Oberbecken (7 Tage), Erzeugung pro Monat, Betriebsart/Standort-Auswahl. * **Messwerte (Sim, Marktbetrieb, mehrere Seeds):** Round-Trip gemessen 73–79 %, 200–290 Zyklen/Jahr; Amortisation Beteiligung ≈18–24 J., Hang-Pumpspeicher ≈25 J., Mini-Pumpspeicher ≈22–36 J. (Streuung nach Standort/Preisprofil), Pacht amortisiert sich über die geringe Kaution schnell, Rendite aber klein. Standort-Betrieb ist bewusst nahe Break-even (kleine Standortlasten) und lohnt vor allem für Überschuss-Nutzung und Netzausfall-Überbrückung. * **Speicherformat:** `S.psp[]` (Anlagenliste, Füllstand `pot` in kWh, Kostenbasis), `S.ext.pmarket`; Migration v3 → v4 legt leere Felder an. ## 7. GPU-Server und GPU-Cloud * **Chassis:** 2U (bis 4× PCIe), 4U (bis 8× PCIe), 8U HGX/OAM (4 oder 8 SXM/OAM mit NVLink bzw. Infinity Fabric). Netzteile 2+2 bzw. 3+3 (Wirkungsgradverlust 6–7 %), Reputationsfreischaltung (8 / 20 / 45). Gewicht und Bodenlast (GPUs 1,8–3,8 kg je Stück, Kaltplatten +14 kg). * **Beschleuniger (Preise/Kennwerte grob 2026):** RTX 4090 24 GB (Consumer, EULA-Risiko), RTX 6000 Ada 48 GB, L40S 48 GB, A100 40 GB PCIe, A100 80 GB SXM, H100 80 GB PCIe/SXM, H200 141 GB, MI300X 192 GB – mit VRAM, TDP (250–750 W), TFLOPS, Preis, Marktmiete (€/GPU-h), AFR, Reputations-Freischaltung und **monatlicher Lieferanten-Allokation** (steigt mit Reputation). Marktindizes für Hardwarepreis (`gpuMul`), Nachfrage (`gpuDemand`, Zufallsprozess) und Mietpreis (`gpuRate`). * **Leistung & Wärme:** Leistung = Basis + CPU + GPU-TDP × Anzahl lebender GPUs × (0,09 + 0,91 × Auslastung) × Netzteilverlust; 8× H100 SXM ≈ 8–9 kW je Server, Rack bis ~43 kW (PDU-Klassen). **Flüssigkühlung je Rack:** Rücktür-Wärmetauscher (~85 % der Wärme, bis 35 kW; im Colo gegen Aufpreis) oder Direkt-Flüssigkühlung (Kaltplatten + CDU, ~75 % ins Wasser, COP ~16, bis 120 kW, nur Container/Halle). Kaltplatten-Server bleiben ohne DLC im Rack offline. * **Netzwerk:** 100G/200G/400G-NICs, ToR mit 100/200/400G, RoCE-Fabric (Storage-/Overlay-Einstellung) mit RDMA-NICs; Training mit mehr als 8 GPUs braucht RoCE + ≥100G-RDMA. * **Produkte:** On-Demand (Stundenabrechnung, schwankende Auslastung), Spot (≈ 38 %, wird von zahlenden Kunden verdrängt), Reserved (12 Monate, ≈ 68 %, Take-or-Pay, ≥40 GB nicht-Consumer), Inferenz-Hosting (24/7, hohe Auslastung, ≥40 GB), Training (2–6 Monate, 8–32 GPUs in 8er-Schritten, ≥80 GB + NVLink). Umsatz = GPUs × Marktmiete × Faktor × Auslastung × 720 h; die Monatsrechnung wird je Tick aus dem Auslastungsmodell neu berechnet. Kunden werden je GPU-Modell (nicht gemischt) zugeordnet. * **Betrieb:** Auslastungsmodell (Tagesgang, Nachfrageindex, Rauschen); Consumer-GPUs im RZ können zu Abmahnungen führen; Abschreibung 5 Jahre – GPU-Cloud ist kapitalintensiv (16× H100 ≈ 16 k €/Monat Umsatz bei 60 % Auslastung, Amortisation lang). * **GPU-Ausfallmodell (ab Save v4, Okt 2026):** Ausfallrate je GPU und Jahr λ = AFR × Last × Temperatur × Alter × Kaltplatte × Schwierigkeit. *Last* = 0,6 + 0,8 × Auslastung (Leerlauf 0,6×, Volllast 1,4×); *Temperatur* = 2^((T_Einlass − 30 °C)/10) (nur über 30 °C); *Alter* = 1 + 0,8·e^(−Jahre/0,35) (Frühausfälle in den ersten Monaten) + 0,1·(Jahre − 3)² (Verschleiß erst nach 3 Jahren); Kaltplatten ×0,7. Basis-AFR: Datacenter 1,6–2,2 % (MI300X 2,6 %), RTX 6000 Ada 2,0 %, RTX 4090 (Consumer) 4,5 %. Ergebnis (H100-Klasse): gut gekühlt/Normalbetrieb ≈ 2,2–2,7 %/Jahr, Dauer-Volllast ≈ 3–3,6 %, heiß (36 °C) + Volllast ≈ 4,4–5,4 %, RTX 4090 Volllast ≈ 6–7 %, heiß ≈ 9–11 %; nach 5 Jahren 3,5–7 %, nach 7 Jahren 6,5–13 % (4090 bis ≈ 24 %). *Vorher (bis Save v3):* AFR × (0,5 + 1,5·Auslastung) × 2^((T−28)/10) × (1 + 2,5·(Jahre/4)²) × 1,5, Basis-AFR 2–3 % (4090: 6 %): im ersten Jahr 5–7 % (4090 ≈ 11–16 %), nach 3 Jahren 13–18 %, nach 5 Jahren >23 % – deutlich zu hoch. * **Garantie/RMA:** Consumer 2 Jahre, Workstation/Datacenter 3 Jahre ab Kauf. Im Garantiezeitraum kostet „GPU ersetzen“ nur 150 €/GPU Handling; Ersatz kommt nach 3–7 Tagen (Server bleibt mit weniger GPUs aktiv). Außerhalb der Garantie oder per „Sofort-Ersatz“: Händlerpreis (0,85 × Listenpreis × Marktindex + 180 €/GPU), sofort. Bestehende Saves bleiben gültig (Alter aus den Assets, neue Felder `rmaN/rmaAt` optional). ## 8. Konto & Spielstände auf dem Server * **Gast-Modus bleibt:** ohne Anmeldung `localStorage` (Schlüssel `dctycoon_save_v1`), auch offline. Nach der Anmeldung lässt sich der lokale Stand in einen Slot importieren; solange ein Server-Slot aktiv ist, wird der Gast-Stand nicht überschrieben. * **Backend:** kleiner Flask-Dienst (`tycoon-api`, gunicorn auf 127.0.0.1:5010, eigene systemd-Unit) hinter nginx unter `/tycoon/api/`; SQLite (WAL) in `/var/lib/tycoon/tycoon.db`; Passwörter Argon2id; Sitzungen als zufällige Tokens (nur SHA-256 in der DB), Cookie `tyc_session` (HttpOnly, Secure, SameSite=Lax, Path=/tycoon/); CSRF-Schutz über Pflicht-Header `X-Tycoon`, JSON und Origin-Prüfung; Rate-Limits (Login 5 Fehlversuche je Benutzer/15 min, je IP 30/15 min, Registrierung 5/IP/h) plus nginx `limit_req`; Spielstand-Validierung (Schema, Version, ≤ 3 MB, ≤ 5 Slots); optimistische Nebenläufigkeit (`rev`/`baseRev`, 409 bei Konflikt); Konto löschen/Passwort ändern. * **Versionierung:** Spielstand-Feld `v` (aktuell 5); `E.load` migriert v1 → v2 (neue Felder für PV, GPU, Marktindizes), v2 → v3 (`S.ext`, `S.land`, `S.hydro`, Statistikfelder) v3 → v4 (`S.psp`, Pumpspeicher-Markt) und v4 → v5 (`S.mine`, `S.offer`, `customer.pm`, `rack.col`, `S.drvBought`; alles lazy/idempotent) und lehnt neuere Versionen ab. Der Server akzeptiert `v` ∈ {1,2,3,4,5} (`SAVE_VERSIONS` in `app.py`). * **Backup:** täglich 03:40 per systemd-Timer (`tycoon-backup`), SQLite-Online-Backup, gzip, 14 Generationen in `/var/backups/tycoon/`. ## 9. Bewusste Vereinfachungen / Ausblick Kein Multi-Tenant-Scheduling je VM (Pool-Modell je Standort), keine Steuern, keine Konkurrenz-KI, keine Strompreis-Tarifzeiten, Kabelwege nur pauschal je Standort, keine Server-Migration zwischen Standorten, keine Spot-Preisbörse mit Wettbewerbern, kein Mehrmandanten-GPU-Sharing (MIG/vGPU), kein Passwort-Reset per E-Mail, kein Multi-Provider-Routing-Detail (nur Qualitätsfaktor). Mögliche nächste Schritte: Wettbewerber, Personal-Spezialisierung, Steuern/Gewinnausschüttung, Tarifzeiten, Netzdienstleistungen/Regelenergie für Batterien, Regelenergie-Vermarktung des Pumpspeichers. ## 10. Balance-Abstimmung (Okt 2026) Automatische Headless-Simulation (`engine.js` in Node, Bot mit einfacher „vernünftiger Spieler“-Strategie, 4 Seeds × 3 Schwierigkeitsgrade × 5 Spieljahre). **Vorher → nachher** (Mittel): Kassenbestand nach 12/24 Mon. Normal 9,5k/10,5k € → 10,1k/21,8k €, MRR nach 36 Monaten 3,1k → 22,8k €, Kunden nach 36 Mon. 215 → 698, Insolvenzen 0/12 → 0/12, Colo-Einstieg im Mittel nach 26 Monaten, Container-DC nach 52 Monaten. Produkte db/mgd verkaufen sich jetzt. Wesentliche Änderungen: Startkapital 36.000 €, Leads ×1,5, Bandbreiten je Produkt gesenkt (Keller-1G reicht), `dia10` im Colo, Reputation weicher (Abzug/Zugewinn), minRep ERP 40/CDN 32/Managed 25/DB 18/Box 0, IPv4-Miete 1,2 €, Admin-Bedarf entschärft, GPU-Mieten (H100 PCIe 2,55 €/h, SXM 3,25 €/h; Spot ×0,45, Reserved ×0,72, Inferenz ×0,90) → einfache Server-Amortisation ≈2,3 Jahre, PV 10 kWp ≈6,6 Jahre (mit 20 kWh ≈5,9, Arbitrage nur mit Speicher), 3. ToR braucht Core-Switch. `S.hardness` (0,4/1/2) skaliert Ereignishäufigkeit (×1,7 bei „Hart“), SLA-Strafen, Leads und Energiepreise. Bekannte Grenzen: der Bot baut kein CDN/ERP/Greenfield; Container-/Greenfield-Ökonomie ist nur grob validiert. ## 11. Mobile Ansicht (Okt 2026) Nur per CSS (`@media(max-width:760px)` am Ende von `style.css`), die Desktop-Ansicht bleibt unverändert; Meta-Viewport `width=device-width, initial-scale=1, viewport-fit=cover`. * **Kopfzeile:** zwei Zeilen im Grid – (1) Home-Symbol + Kennzahlen als **einzeilige, horizontal scrollbare** Leiste (Spielzeit, Kasse, MRR, Kunden …), (2) Geschwindigkeits-Tasten (je ≥44 px, volle Breite) + Konto-Chip (gekürzt). Marke ausgeblendet. Sticky-Anteil vorher 50 % (390×844) / 62 % (360×740), jetzt 12 % / 14 %. * **Tabs:** einzeilige, horizontal scrollbare Leiste (scrollt mit dem Inhalt weg), Tasten 44 px hoch. Kopf + Tabs zusammen ≈ 150 px (17–20 %), vorher 54–67 %. * **Tap-Ziele:** Buttons, Unter-Tabs, Selects, Eingaben mindestens 44 px, Schrift in Eingabefeldern 16 px (kein Zoom auf iOS). * **Tabellen/Konfigurator:** Tabellen scrollen horizontal in ihrer Karte, Grid-Layouts einspaltig, Karten mit `min-width:0` – keine horizontale Seitenüberbreite (in allen Tabs und Unter-Tabs getestet). * **Test:** `tycoon-test/mobile.js` (Headless-Chrome mit Mobile-Emulation 390×844, 360×740, 412×915; prüft Kopfhöhe ≤16 %, Überbreite, Tap-Ziele, JS-Fehler; Screenshots). ## 11b. Verkauf, Rückbau, Standort aufgeben (Okt 2026, ohne neue Save-Version) * **Gebrauchtpreis (einheitlich):** Zeitwert = Kaufpreis × 0,5 × (0,2 + 0,8 × Restlaufzeit-Anteil), Restlaufzeit aus dem Anlagen-Alter (`S.assets`, Nutzungsdauer wie bei der Abschreibung). Er liegt immer ≤ 50 % des Kaufpreises, daher bringt Kaufen → sofort Verkaufen nie Gewinn (Test `bal/sale.js`; auch für Land/Wasserkraft/Pumpspeicher geprüft). Gilt für Lager (`E.sellInv`, vorher pauschal 50 %), ausgebaute Kühlgeräte (`E.removeCooling`, vorher ohne Erlös), Racks, PDUs, USV, Generatoren, PV, Speicher, Server und Netzwerkgeräte. * **Zuordnung:** Anlagen tragen `own` (Standort) und `ref` (Rack bzw. Geräte-ID) in `S.assets`. Alt-Saves werden beim Laden einmalig (`S.ownTag`) aus Asset-Schlüsseln und Bestand zugeordnet (ersetzte PDUs/Kühl-Kits werden dabei verworfen); `SAVE_V` bleibt 4. * **Rack entfernen (`E.rackSaleInfo/sellRack`):** leer jederzeit; mit Geräten nur per **Zwangsentleerung** (Dialog): Geräte ins Lager oder verkauft (Zeitwert, 25 €/Gerät Demontage). Erlös Rack + PDU + Flüssigkühl-Kit (Zeitwert) minus Demontage (120 € + Anteil 2–5 %). **Colo-Rack:** Kündigung = 1 Monat Miete, Mindestlaufzeit 3 Monate. Rack-Namen bleiben eindeutig. * **Standort aufgeben/verkaufen (`E.siteSaleInfo/sellSite`):** nie der letzte Standort. *Keller:* frei aufgebbar. *Colo:* Kündigungsfrist 3 Monate, Mindestlaufzeit 12 Monate (Rest als Miete: Fixmiete + Racks), Rückbau 50 % der Einrichtung + 200 €/Rack. *Container/Greenfield:* Marktwert = Einrichtung × (0,30 + 0,50 × Restwert-Anteil aus der Abschreibung) × Lage (0,94, +0,04 mit ≥2 Transits, +0,04 mit IXP) × Auslastung (0,92–1,08 je nach belegten Racks) + Einbauten (Einhausung, Boden, Anschluss zum Zeitwert) − 6 % Nebenkosten − 3 Monate Pachtkündigung. Fest installierte Technik (Racks, PDU, Kühlung, USV, Generator, PV, Speicher, Fabric) wird zum Zeitwert verkauft (− 3–6 % Rückbau); Server/Netzwerkgeräte nach Wahl ins Lager oder verkauft. * **Kunden:** werden auf andere Standorte umgezogen (gleiche Zuordnungsregeln wie bei Neukunden, GPU-Kunden nur auf Standorte mit freiem Kontingent des Modells; 0,5 Monatspreis Gutschrift, Zufriedenheit −0,1); was nirgends passt, wird sonderkündigt (1,5 Monatspreise Vertragsstrafe, Reputation −0,4 je Kunde, max. −4). * **Verknüpfte Anlagen:** Land-PV, Wasserkraft und Pumpspeicher mit Direktlieferung/Standort-Betrieb an den aufgegebenen Standort wechseln auf einen anderen Nicht-Colo-Standort, sonst Netzeinspeisung bzw. Marktbetrieb. * **Kredit:** das Kreditlimit sinkt mit dem Buchwert; liegt der Kredit danach darüber, erfolgt eine **Sondertilgung** aus dem Verkaufserlös (nur soweit Kasse vorhanden). * **UI:** Standorte → Racks: „Rack entfernen …/Rack kündigen …“ je Rack, unten „Standort verkaufen/aufgeben/Colocation kündigen …“ (beim letzten Standort deaktiviert). Beide öffnen einen **Bestätigungsdialog mit Kostenübersicht** (Posten, Saldo, Kunden, Kasse danach; Option Lager/Verkauf; Spiel pausiert; mobil bildschirmbreit, Tasten ≥44 px). Lager zeigt Zeitwert statt „50 %“. ## 11c. Wartung & Auto-Reparatur (Okt 2026, ohne neue Save-Version) Neuer Tab **Wartung** (`renderOps`, Engine-Block `ops*` in `engine.js`, Parameter `D.ops` in `data.js`). Zustand lebt lazy in `S.ops` (Einstellungen, Teilelager, offene Tickets, Historie, Statistik) und `site.set.autoRepair`; ältere Saves/Engines ignorieren die Felder (kein `SAVE_V`-Bump, kein `tycoon-api`-Neustart). * **Tickets:** Jeder Hardware-Defekt wird ein Ticket (`opsSync`): Laufwerk (bestehendes Modell), GPU (bestehendes Ausfall-/RMA-Modell), neu Netzteil (Tower: Server aus; redundant: läuft, Ausfallrisiko ×3), Lüfter (Server wird heißer/drosselt), RAM (Server aus), Optik/Link (Server vom Netz). Neue Defekte würfeln über den separaten Ext-PRNG (`xr`), der Haupt-Zufallsstrom und die Balance bleiben unverändert. Serverhänger und Kühlgeräte-Ausfälle erscheinen als Timer-Tickets. * **Auto aus (Standard):** wie bisher – Laufwerke/GPUs warten auf den Spieler, andere Defekte behebt ein Dienstleister nach 24–72 h (Teil + 120 € Anfahrt). Manuell reparieren (`E.opsRepair 'now'`) nutzt Lagerteil oder Express-Teil (×1,4 + 45 €); Ersetzen über die bestehenden Aktionen schließt das Ticket ebenfalls. Manuelle Ausgaben zählen nicht auf das Auto-Budget. * **Auto an (global + je Standort):** Admins arbeiten Tickets nach Priorität (SLA/Ausfall zuerst oder FIFO) ab. Kapazität = `max(0.3, Admins+1 − Bedarf·0.7) × Abdeckung(Schichtmodell)`; Tempo je Erfahrungsstufe (1/1,3/1,7). Schichtmodelle: Bürozeiten, erweitert (6–22 Uhr, +6 % Personal), Rufbereitschaft (nachts halbe Kapazität, +12 %); Überstunden außerhalb Mo–Fr 8–17 Uhr 45 €/h. Erfahrungsstufe (Schulung 6.000/14.000 €, braucht ≥ Stufe Admins) erhöht Lohn (×1,12/×1,28), senkt Fehlerrate und verkürzt Serverhänger/Kühlausfälle (`opsAutoF`). * **Teile:** Teilelager (Laufwerke je Modell, GPU je Modell, DIMM, Netzteil, Lüfter, Optik) mit Sollbestand (tägliche Nachbestellung), Lagerkosten 1,2 %/Monat auf den Warenwert. Fehlt das Teil und „automatisch bestellen“ ist an, bestellt der Admin (Lieferung 24–72 h, 1,5 % DOA-Risiko mit weiteren 24 h). GPU in Garantie: Admin leitet RMA ein (Pauschale, 3–7 Tage). * **Standortentfernung:** Colo-Standorte nutzen Remote Hands (Wartezeit 2–6 h, 90 €), Container/Green mit Anfahrtszeit. * **Risiko:** Fehlbedienung je Eingriff 3 % / 1,8 % / 1 % (Stufe 1–3; Colo ×1,6, nachts ×1,3) → Server hängt 2–6 h, 35 % Folgeausfall eines weiteren Laufwerks. Bleibt als Ticket sichtbar. * **Budget:** Monatslimit (unbegrenzt/500/1.500/3.000/6.000 €) für Teile, Überstunden, Remote Hands; Tickets warten danach auf „Budget freigeben“. * **Reporting:** Kennzahlen (offene Tickets, MTTR 90 Tage und je Akteur, Ausfallstunden, Fehlbedienungen/DOA/RMA, Kosten Monat/gesamt/Lager), Teilelager-Tabelle, Ticketliste mit Aktionen, Reparaturhistorie. SLA-Wirkung ergibt sich direkt: kürzere Ausfälle → weniger Downtime-Minuten, weniger Gutschriften/Abwanderung. * **Mobil:** Listen als Karten (`.opitem`), Tap-Ziele ≥ 44 px, kein Überlauf (Test `ui7.js mobile`). * **Tests:** `bal/ops.js` (Tickets, manuell/auto, Budget, MTTR vs. Admins/Schichten/Skill, Colo-Remote-Hands, Bot-Langläufe, kein NaN), `ui7.js` (Desktop + `mobile`). ## 11d. Strom & Kühlung (Okt 2026, ohne neue Save-Version) **Ergebnis der Code-Prüfung (Stand vor dieser Änderung): überwiegend ja, teilweise nein.** * *War schon drin:* Gesamtlast `facKW = IT + Kühlstrom + USV-Verluste + 2 % Verteilung + Standort-Overhead + Fabric + PV-Technik` (Colo: `IT × PUE`). Kühlstrom = Wärme ÷ COP je Kühlart (COP abhängig von Zulufttemperatur und Außentemperatur), Freikühlung nur unterhalb der Grenztemperatur mit Lüfterstrom (anteilig), Flüssigkühlung (Pumpen/CDU über COP), Wärmelast inkl. USV-Verlusten und PV-Technik. `facKW` ging bereits in Stromkosten (Stundenabrechnung), Netzbezug, PV-/Batterie-/Wasserkraft-/Pumpspeicher-Management (Last), Hausanschluss-Überlast und PUE/Nachhaltigkeits-Score ein. * *Fehlte bzw. war nur teilweise:* (1) Generator-Eignung (`genKW ≥ 0,8·Last`) und Tankreichweite rechneten nur mit der IT-Last, obwohl das Aggregat auch Kühlung und Verluste tragen muss; (2) USV-/Batterie-/Pumpspeicher-Überbrückung rechnete nur mit IT, nicht mit Lüftern/Pumpen/In-Row; (3) kein Leerlaufverbrauch der Kühlgeräte (Lüfter, Pumpen, Steuerung) – PUE bei Teillast war zu gut; (4) USV-Verluste nur auf IT; (5) keine Aufschlüsselung IT/Kühlung/Verluste über die Zeit. * *Jetzt:* `D.coolIdle = 0,06` (Leerlauf = 6 % der elektrischen Nennleistung `kW/COP` jedes laufenden Kompressor-/Kaltwassergeräts). `rt.critKW = IT + kritische Kühlung` (Freikühl-Lüfter, Flüssigkreis/Pumpen, Leerlauf, In-Row-Anteil) ist die USV-/Batterie-/PSP-Last; USV-Verluste fallen auch darauf an. Der Generator trägt `facKW` (Eignung `genKW ≥ 0,8·facKW`, `genH` mit Gesamtlast). `rt.pw` = Zerlegung `{it, cool, loss, dist, oth}` (Summe = `facKW`), `rt.coolParts` = `{free, mech, liq, idle}`. Monatsstatistik je Standort `st.en` (`it, cool, loss, dist, oth, free, mech, liq, idle, grid, eur, h, freeH`, laufender Monat + Vormonat, lazy, Saves ohne Feld laden normal). Anzeige: Standort → Kühlung & Thermik → „Energie & PUE“ (Stapelbalken IT/Kühlung/Verluste/Sonstiges, Kühlung nach Freikühlung/Kompressor/Pumpen/Leerlauf, Monatsenergie, Ø-PUE, Netzbezug, Kosten und Kühlkostenanteil, Freikühlungs-Stunden) und Finanzen → „Stromverbrauch nach Verbraucher“. * *Auswirkung:* Keller-PUE ≈ 1,42 → 1,46 (Leerlauf + USV-Anteil), Colo unverändert (PUE-Aufschlag). Bot-Balance im Rauschen (Uptime 99,6 %). Tests: `bal/cool.js`/`cool2.js` (PUE-Vergleich), `ui8.js` (Desktop + `mobile`). ## 11e. Keller/Garage: Heimanschlüsse, Funk, Mehrfach-Uplink (Okt 2026, ohne neue Save-Version) Neue Transit-Typen in `D.transit` (`home:true`, nur Standort Keller): **VDSL2 100/40**, **Kabel 1000/50** (CGNAT), **Glasfaser 1000/500**, **Starlink Residential/Business**, **LTE**, **5G** (zusätzlich zum bisherigen Business-DIA 1G). `speed` = nutzbarer **Upload** in Gbit/s (Kundentraffic geht raus) und begrenzt wie bisher über `tCapG` die Kundenzahl (Uplink-Bandbreite), `down` ist Anzeige. Colo/Container/Greenfield behalten Transit/BGP unverändert; im Keller bleibt BGP/eigenes Prefix unmöglich. * **Kosten:** Monatspreis + optional feste IPv4 (`staticFee`), Einmalkosten Hardware (Modem/Router/Dish, als Asset `wan` mit `own`=Standort, abgeschrieben) + Anschlussgebühr; Laufzeiten (DSL/Kabel/FTTH 24 Monate, LTE/5G 1 Monat, Starlink monatlich kündbar); Außenantenne für LTE/5G 180 € (+15 % Signal). * **IP/CGNAT:** DSL/FTTH dynamische IPv4 (erreichbar, Qualität ×0,93), Kabel/Starlink/LTE/5G hinter CGNAT: ohne feste IPv4 (Aufpreis; Starlink Residential gar nicht), Tunnel-Dienst (29 €/Monat, +15 ms, max. 250 Mbit/s) oder Bonding sind die Kunden **nicht erreichbar** (`rt.wan.blocked` → Standort „down“, keine neuen Kunden). * **Funk-/Satellitenmodell:** Stündlicher Durchsatzfaktor `c.qf` (Abendstau, Signal je Lage per Hash der Standort-ID, Rauschen), Wetterereignisse (Starlink), zufällige Ausfälle (nur über Ext-PRNG, Hauptstrom unverändert), Datenvolumen `c.vol` mit Drosselung nach Kontingent (LTE 500 GB/5G 1 TB → ×0,06; Starlink nach 1 TB nachrangig ×0,35), Monatsreset. * **Mehrfach-Uplink:** ab dem 2. Uplink Pflicht: **Multi-WAN-Router** (`rt-mwan`). Modi je Standort (`set.wan.mode`): *Failover* (erste verfügbare Leitung), *Load-Balancing* (Summe × 0,95, gewichtete Latenz), *Bonding* (Aggregations-Dienst 79 €/Monat: Summe × 0,9, feste IP, +12 ms, weniger Jitter). Kein Vertragslimit mehr (siehe 11f); im Keller darf derselbe Typ mehrfach gebucht werden. Ohne Multi-WAN-Router wird nur der erste Uplink genutzt. * **Wirkung auf Kunden:** Produkte haben Latenzempfindlichkeit (`D.wan.sens`); Zufriedenheit sinkt mit Latenz > 30 ms und Jitter > 8 ms; harte Obergrenzen (`D.wan.maxLat`: CDN 35 ms, GPU-Inferenz 70 ms, Datenbank 90 ms) verhindern die Annahme; SLA-Strafen/Reputation ergeben sich über die Ausfallstunden. * **Kündigen/Verkaufen:** `E.wanTermInfo/removeTransit` (Dialog mit Kostenübersicht): Restlaufzeit × 0,8 als Vertragsstrafe, Hardware zum Gebrauchtpreis (≤ 50 %); beim Aufgeben des Standorts fließen Vertragskosten und Hardware-Erlöse in die Saldo-Übersicht ein. * **Save:** neue Felder lazy (`set.wan`, `c.t0/static/ant/qf/vol/thr/wx`), kein Versions-Bump. * **Tests:** `bal/wan.js` (alle Typen, CGNAT/feste IP/Tunnel/Bonding, Failover, Datenvolumen, Ausfälle 2 Jahre, Kündigung, Standortverkauf, Latenzgrenzen), `ui9.js` (Desktop + `mobile`). ## 11f. Transit-Verträge ohne festes Limit (Okt 2026, ohne neue Save-Version) Die harte Obergrenze „max. 3 Transit-Verträge je Standort“ ist entfernt. Begrenzt wird nur noch physisch: **freie Router-Ports** (`Verträge + IXP-Ports ≤ Summe der Router-Ports`: Edge-Router 2, Multi-WAN-Router 4, BGP-Router 6, Carrier-Router 12; weitere Router erhöhen die Zahl), **Router-Port-Geschwindigkeit** (Vertrag ≤ schnellster Port), Router-Gesamtdurchsatz (`capGbps`) als Kapazitätsdeckel, BGP-Voraussetzungen (AS, Prefix, BGP-Router) und für Standorte ohne BGP (Colo-DIA) weiterhin ein DIA-Vertrag, weil ohne BGP kein Lastverteilen möglich ist. Im Keller sind mehrere Verträge (auch gleicher Typ) mit Multi-WAN-Router möglich. Berechnungen (Kapazität, 95/5- und 90/10-Abrechnung je Vertrag, Qualität, Lastverteilung, Failover) iterieren je Vertrag linear; getestet mit 12 Verträgen (Carrier-Router) über 24 Monate (< 1 s, kein NaN). Tests: `bal/many.js`, `ui10.js` (Desktop + `mobile`). ## 11g. Racks einklappen, Rack duplizieren (Okt 2026, Save v5) * **Einklappen** – `rack.col` (bool, im Spielstand). Kopfzeile jedes Racks ist Klickfläche (≥ 36 px, `aria-expanded`); eingeklappt bleibt eine Zusammenfassung: Name/Typ, HE-Belegung (Balken), kW + Einlasstemperatur, PDU-/Geräte-Auslastung, Alarme (Hitze, Überlast, Netz). „Alle einklappen/ausklappen“ je Standort (`E.setAllRacksCol`). Engine: `E.setRackCol(S,site,rack,on)`. * **Duplizieren** – `E.rackCloneInfo` (Vorschau) und `E.cloneRack` (Ausführung). Kosten zu **aktuellen Marktpreisen**: Rack, Einhausung, PDU(s), Flüssigkühlung, Geräte (Server inkl. Lizenzen, Switches, Router, Miner), Kabel/Ports, Blindblenden; Lieferzeiten/Quoten (Laufwerke/GPUs) und Reputationssperren gelten wie beim Normalkauf. Prüfungen (einzeln im Dialog mit ✓/✗): Rack-Typ am Standort, freier Stellplatz, Geld, Rack-Traglast, Bodenlast (kg/m²), PDU-Kapazität, B-Einspeisung vorhanden, Hauptanschluss nach Duplikat, Kühlleistung/Abwärme, Switch-Ports/Uplinks. Kopiert werden Geräte + Positionen, Server-/Switch-Konfiguration, Kabel (ToR-Zuordnung), Rack-Einstellungen (kW im Colo, Flüssigkühlung, Blindblenden). VLAN/Overlay/Fabric sind Standort-Eigenschaften und gelten damit automatisch auch für das Duplikat. * **Atomar** – Schlägt irgendein Schritt fehl, werden Kasse, Racks, Lager, Assets und Log auf den Stand vor dem Klick zurückgesetzt (Test mit künstlichem Fehler beim 3. Gerät). Bestätigungsdialog zeigt Kostenaufschlüsselung; Fehlermeldungen im Klartext („Nicht genug Geld: 54.871 € nötig, Kasse 1.000 €.“, „Standort voll (max. 6 Racks).“, „PDU B: der Standort hat keine B-Einspeisung mehr.“). ## 11h. Krypto-Mining mit Markt (Okt 2026, Save v5) **Daten:** `D.mine` (data.js), Engine-Block „Mining“ in engine.js (`ensureMine`, `mineMarket`, `mineNetwork`, `mineHour`, `mineMonth`), UI: Reiter „Krypto-Mining“ (Markt · Anlagen · Rechner · Wallet & Handel · GPU-Leerlauf) und Beschaffung → „Mining-Hardware“. Zustand `S.mine` (Münzen, Wallet, Ledger, Trades, Marktregime). * **Münzen (simuliert, 5):** BTC (SHA-256, ASIC), LTC (Scrypt, ASIC), KAS (kHeavyHash), ETC (Etchash), RVN (KawPow) – die drei letzten per GPU. Kurs: logarithmischer Zufallspfad mit Marktfaktor (Regime Bulle/Bär/Seitwärts, 40–260 Tage), Beta je Coin, Tagesvolatilität 3–7 %, mittelreversiv zu einem Trendkorridor, Krypto-Crash (~1,4/Jahr, −18…−50 %) und coin-spezifische Ausreißer; Kurs auf 0,07…14 × Trend begrenzt. * **Netzwerk:** Gleichgewichts-Hashrate `H_eq = Emission · Kurs-EMA(30 d) / Erlös-Ziel` (Ziel = Referenz-Miner bricht bei `pRef` €/kWh inkl. Abschreibung über 912 Tage gerade even; Referenz-Effizienz −14 %/J SHA-256, Preis −18 %/J). Fremd-Hashrate folgt mit Rate 0,004/h (≈ 10 Tage), Difficulty-Retarget BTC 14 d, LTC 7 d, GPU-Coins täglich. **Halving** BTC nach 470 Tagen, dann alle 1458 d (Logeintrag, Ertrag je Hash halbiert sich bei gleichem Kurs; die Difficulty fällt mit Verzögerung). Eigene Hashrate verdünnt (Share = eigene / (Difficulty + eigene)). * **Pool:** FPPS 2,5 % (stabil), PPS+ 2,0 %, PPLNS 1,0 % (Glück-σ 12 %); Auszahlung erst ab Mindestmenge (`minPay`), danach Wallet; je Coin automatisch **verkaufen** oder **HODL**. * **Wallet & Handel:** Verkauf zum Marktkurs minus Spread 0,4 %, Gebühr 0,15 %, Slippage `0,5·Betrag/Markttiefe` (BTC 60 Mio €, Altcoins 1,4–6 Mio €); es gibt **keinen Ankauf von Coins** – Coins entstehen nur durch Mining, Kaufen+Verkaufen ist also nie ein sicherer Gewinn. Optionale **Steuer** 30 % auf den Monatsgewinn (Erträge − Strom − Zuschläge − Verschleiß − Abschreibung − Reparatur − Bußgelder) mit Verlustvortrag. Handelshistorie (80 Einträge). * **ASIC-Hardware (9 Modelle):** S19j (gebraucht, 78 dB), S21, S21 XP, S21 XP Hyd (Wasser, 58 dB), später S23 Hyd (ab Jahr 1,5), S25 Hyd (ab Jahr 3,5); Scrypt L7/L9/Gen3 (ab Jahr 2). Brauchen Strom (3–5,7 kW!), Kühlung (Wärme = Leistung; Hyd-Modelle brauchen Flüssigkühl-Rack, RDHx/DLC), RJ45-Port am ToR; Ausfall (AFR 16 %, steigt mit Alter/Temperatur, thermische Abschaltung ab 46 °C, Reparatur 12 % Neupreis + 80 €), Wertverlust durch Difficulty/Effizienzfortschritt, Gebrauchtwert ≤ 50 % Neupreis und ≤ was die Hardware noch verdient. * **Standorte:** Keller – Lärm (dB(A) am Nachbarn; Limit 60 dB, tägliche Prüfung: Verwarnung, dann Bußgeld 300–1500 € bzw. Stilllegung 5–10 Tage; Schalldämmung 6.500 € + 400 €/Rack: −14 dB); Colo – Mining-Zuschlag 70 €/kW/Monat, max. 75 % Mining-Anteil; Container/Greenfield ohne Zuschlag (PUE entscheidet). Mining-Anteil > 50 % der IT-Last kostet Reputation (ESG-Kritik, −0,25/−0,6 pro Monat). * **Rentabilität:** Rechner je Gerät/Standort (`E.mineProfit`): Ertrag, Strom (× PUE, Standortpreis), Zuschläge, Netto, Netto inkl. Kapitalkosten, **Break-even-Strompreis** (effektiv/Zähler) und Payback. * **Balance (Headless-Simulation, `bal/mine-sim.js`, 2 J., 16–24 Seeds, 10 Miner in 2-Rack-Farm mit RDHx):** Marge auf Einsatz (Erlös+Wallet+Restwert − Strom − Reparatur − Hardware)/(Strom+Hardware): Container S19j −45 %, S21 −15 %, **S21 XP +3 % ± 35 %** (56 % der Läufe positiv), S21 Hyd +13 %, L7 −28 %, L9 −2 %; Start in Jahr 2: S21 XP −17 %, S23 Hyd +7 %, L11 +15 % (σ 30–39 %). Greenfield (kleine Farm, PUE ≈ 2) −20 %, Colo −39 %, Keller (S19j) ≈ −100 %. Ergebnis: im Schnitt nahe Break-even, hohe Streuung, Standortwahl dominiert; kein Geldautomat. Kalibrierhebel: `pRef` (0,40), `hashK`, `peDays`, `ref.*.pm`. ## 11i. GPU-Leerlauf-Mining (Okt 2026, Save v5) * Schalter: **global** (`S.mine.gpuOn`, Standard aus), **je Standort** (`site.set.mine`), **je Server** (`server.mine`); Mindest-Marge (`S.mine.minMargin`, Standard 10 %): Mining nur, wenn Ertrag > Grenzkosten·(1+Marge). * **Kunden haben Vorrang:** Mining nutzt nur GPUs, die nach der Kundenzuteilung (`usedG`) frei sind; sobald GPU-Aufträge kommen, werden Mining-GPUs sofort freigegeben (kein Reservierungsverlust). Test: GPU-Kunden mit Mining = ohne Mining (704 vs 704 Kunden-Stunden). * Hashrate je GPU-Klasse (`gpuClassF`: Consumer 1,0 · Workstation 0,9 · Datacenter-HBM 0,38) × TFLOPS bzw. Speicherbandbreite je Algorithmus; Power-Limit-Anteil `pl` je Algorithmus (kHeavy 0,80, Etchash 0,62, KawPow 0,88 der TDP). Zusatzleistung/Wärme gehen in Strom, PUE und Kühlung ein; Verschleiß 0,5 · Preis/3 J. als Grenzkosten. * Ergebnis: **RTX 4090** Ertrag/€ Kaufpreis ≈ 5× H100; reiner Mining-Kauf lohnt für die 4090 nur marginal (Netto inkl. Kapital ≈ +0,3 €/Tag), H100/H200 stark negativ (−20…−29 €/Tag) – als Leerlaufnutzung vorhandener Karten aber positiv (+6…10 €/Tag, weit unter dem Vermietungserlös). * Finanzen: eigene Zeile „Mining-Erträge“ (`fin.mine`), nicht in Kundenumsatz/MRR. ## 11j. Angebote an/aus und Preisfaktor bis ×5 (Okt 2026, Save v5) * **„Modelle an Servern“ im Code:** Server sind ein Kapazitäts-Pool je Standort; es gibt keine Zuordnung Server → Produkt. Umgesetzt wurde deshalb der Schalter je **Produkt-Angebot** (VPS S/M/L, Managed, SaaS, GPU-On-Demand/Spot/Reserved/Inference/Training …) und je **GPU-Modell** (GPU-Cloud wird je Modell angeboten), jeweils **global** und **je Standort** (`S.offer.off`: `p:`, `s::`, `m:`, `ms::`). * **Regel:** Deaktivierte Angebote bekommen **keine Neukunden/Aufträge**; laufende Verträge werden weiter bedient (bis Kündigung/Laufzeitende); reservierte GPU-Verträge werden bei Ablauf nicht verlängert. UI: Checkboxen in Kunden & Betrieb (Status „aktiv“ / „aus (nur Bestand)“, Quelle global/Standort) und GPU-Modelltabelle. `E.offerOn`, `E.setOffer`, `E.offerStatus`. * **Preisfaktor:** 0,5…**5** (`D.priceMin/priceMax`). Nachfrage ∝ `pf^(−ε·(1+0,25·max(0,pf−1)))`, `ε = elastK(2,4) · ε_Produkt · (1,15 − 0,4·Rep/100)`; ε_Produkt: Web 2,8, VPS 2,6/2,4/2,2, Managed 1,3, ERP 1,0, GPU-Spot 3,0, GPU-Training 1,1 … (Premium/Spezial unelastischer; höhere Reputation = weniger preissensibel). Kündigungsfaktor `1 + 2,5·ε/2,4·(pf−1)^1,3` (bis ×9–16 bei ×5), Preisfaktor je Kunde wird bei Vertragsabschluss gemerkt (`customer.pm`). UI zeigt Nachfrage-/Kündigungsreaktion je Produkt. * **Balance (Bot, 4 Seeds, 3 Jahre, alle Produkte gleicher Faktor, Σ Netto):** ×1 75k · ×1,25 258k (Optimum) · ×1,5 219k · ×2 36k · ×3/×5 ≈ 0 Kunden, Verlust −27k. Vorher (Basis, Maximalfaktor ×2): ×1,5 437k · ×2 610k. ×5 ist damit keine Geldmaschine; der Bot-Vorteil bei ×1,25–1,5 ergibt sich aus den knappen Basismargen (Umsatzindex ×5: Web 0,000, ERP 0,004). ## 11k. Neue Speichermedien (Okt 2026, Save v5) | ID | Medium | TB | W (aktiv) | Preis € | AFR | Durchsatz | IOPS | Garantie | frei ab Rep / Jahr | Quote | |---|---|---|---|---|---|---|---|---|---|---| | sata-32 | Seagate Exos M 32 TB (ST32000NM004K), SATA 3,5", 7,2k, HAMR/CMR | 32 | 8 | 780 | 1,7 % | 285 MB/s | 170 | 5 J. | Rep 30 / Jahr 1 | 80 Stk. | | sata-30 | WD/HGST Ultrastar DC 30 TB (HC-Klasse, SMR/UltraSMR) | 30 | 7,5 | 650 | 1,7 % | 260 MB/s | 170 | 5 J. | Rep 20 / Jahr 0,5 | 120 | | sata-28 | Ultrastar DC 28 TB (SMR/UltraSMR) | 28 | 7,5 | 560 | 1,6 % | 260 MB/s | 170 | 5 J. | Rep 12 / sofort | 200 | | nv-122 | Enterprise-NVMe U.2/U.3 QLC 122,88 TB, PCIe 4, 0,3 DWPD | 122,88 | 26 | 14.500 | 0,7 % | 3,0 GB/s | 900k | 5 J. | Rep 40 / Jahr 1,5 | 30 | | nv-61e | NVMe E3.S QLC 61,44 TB, PCIe 5, 0,7 DWPD | 61,44 | 25 | 7.600 | 0,6 % | 3,5 GB/s | 1,1 Mio | 5 J. | Rep 30 / Jahr 1 | 60 | | nv-61 | NVMe U.2/U.3 61,44 TB, PCIe 4, 0,6 DWPD | 61,44 | 24 | 7.000 | 0,6 % | 3,0 GB/s | 900k | 5 J. | Rep 25 / Jahr 0,75 | 60 | | nv-30 | NVMe U.3 30,72 TB, PCIe 5, 1 DWPD | 30,72 | 22 | 3.700 | 0,5 % | 4,5 GB/s | 1,4 Mio | 5 J. | Rep 10 / sofort | 120 | * **Hinweis Spezifikationen:** Kennwerte sind Spielwerte in realistischer Größenordnung, keine Datenblätter. Exos M 32 TB: laut Hersteller HAMR (Mozaic 3+), konventionell (CMR), SATA; die WD/HGST-Ultrastar-Modelle 28/30 TB sind im Spiel generisch als „Ultrastar DC“ mit SMR/UltraSMR (HC680/HC690-Klasse) beschrieben; SATA/SAS je Modell. Preise grob, fallen wie alle Laufwerke mit der Zeit. * **Formfaktor/Kompatibilität:** HDDs 3,5" nur in LFF-Gehäusen; U.2/U.3 in SFF/NVMe-Gehäusen; **E3.S** nur in Gehäusen mit Flash-Backplane (`e3s`: 1U, 2U-SFF, GPU-4U, HGX-8U). Fehlermeldung nennt den Grund. * **Progression/Lieferung:** Freischaltung über Reputation (`minRep`) und Jahr (`avail`); Lieferkontingent je Medium (`alloc · (1+Rep/60)`, `S.drvBought`) wie bei GPUs – große Medien später, knapp und teuer. * **Rebuild/Risiko (`D.drvRb`):** Dauer `h = TB·10⁶ / (MB/s·0,30) / 3600` (SMR ×1,6): 20 TB HDD ≈ 74 h, 32 TB ≈ 104 h, 28 TB SMR ≈ 160 h. Während des Rebuilds steigt die Ausfallrate der übrigen Platten (Stressfaktor HDD ×2,0, SSD ×0,8), ein zweiter Ausfall = Datenverlust (lokales RAID Faktor 1,0, Ceph/Cluster 0,15), Leistung −6 % während Rebuild (calcSite). Server-Detail zeigt Rebuild-Status/Restzeit. ## 11l. Tests v5 (Okt 2026) * **Node `tycoon-test/eng-new.js` (95 Prüfungen, `TYC= node eng-new.js`):** Einklappen (inkl. Save-Roundtrip), Rack-Duplizieren (Vorschau = Abbuchung, Config/Kabel/IDs, Fehlerfälle Geld/Platz/PDU-B, Atomarität), Mining/Markt (Ledger, Rentabilität, Verkauf unter Kurs, Reproduzierbarkeit, Markt unabhängig von Spielerhardware, 6 Jahre ohne NaN, Halving, Steuer, Keller), GPU-Leerlauf (Standard aus, global/Standort/Server, Kundenpriorität, Finanzzeile, 4090 vs. H100), Angebote (keine Neukunden, Bestand läuft weiter), Preis (×5-Klammer, Monotonie, Umsatzindex, Kündigungen), Speichermedien (Rep-Sperre, Quote, E3.S-Regel, Rebuild-Dauer, 3 J. Lauf), Migration v1 und v4 → v5 + 6 Monate, v6 abgelehnt, Performance (1 J. Mining-Simulation < 8 s, Serialize+Load < 1,5 s). * **Browser `ui11.js` (Desktop + Mobil 390×844):** Einklappen/Zusammenfassung/Alle, Persistenz, Duplizieren-Dialog (Kosten, Prüfungen, Bestätigen, Fehler bei zu wenig Geld), alle Mining-Reiter ohne NaN, Kursdiagramm, GPU-Schalter, Wallet-Verkauf, Mining-Hardware-Shop, Konfigurator mit 28/30/32-TB-HDD und 61,44/122,88-TB-NVMe, Preisregler ×5, Angebots-Checkboxen, Finanzzeile, kein horizontaler Überlauf mobil. * Bestehende Tests angepasst (SAVE_V 5 in ui5/ui3) und unverändert grün: ui-test, ui2–ui10, mobile.js, ui3 gegen die öffentliche URL. Balance-Skripte: `bal/mine-sim.js`, `bal/farm.js`, `bal/gpup.js`, `bal/price-sim2.js`, `bal/drv1.js`, `bal/clone1.js`. Nicht-Mining-Wirtschaft unverändert (Bot ×1: identische Σ Netto vor/nach). ## 11m. Ausfallraten-Korrektur und Spieltempo (Okt 2026, ohne neue Save-Version) **Meldung:** Bei Tempo ×5 (Stufe 4, „5 Tage pro Sekunde“) fallen gefühlt jeden Monat ≥ 10 GPUs/Laufwerke aus. **Befund (Headless-Simulation):** * **Keine Tempo-Abhängigkeit.** Die Engine kennt keine Echtzeit; alle Hazards sind pro Tick (1 h) als `Rate/8760 × Faktoren` gewürfelt. Die UI-Schleife (`RATES=[0,2,8,30,120]` Ticks/s, `E.step(S, min(n,60))`) kann bei hohem Tempo höchstens Ticks verlieren, nie zusätzliche würfeln. Gleiche Seeds liefern bei Tempo 1–4 identische Ausfälle und Kasse (40/40 Läufe in Node-UI-Schleife, zusätzlich echter Chrome Tempo 3 vs. 4). * Wahrgenommen wird: ein Spielmonat dauert bei Tempo 4 nur ~6 s, dazu kam eine Toast-Flut je Ausfall. * **Echte Überhöhungen:** (1) Laufwerks-Hazard war mit hartkodiertem Faktor 1,4 multipliziert (HDD-Flotte AFR 2,41 % statt ~1,6 %); (2) Server-Hänger implizit alle 1,3 Jahre je Server (0,46–0,81/Server-Jahr, ca. 6 pro Monat bei 100 Servern); (3) Mining-Dauerlast wurde doppelt gezählt (Lastfaktor über `s._gu` **und** zusätzlich `(1+0,4·_mf)`; GPU-AFR 2,71 % statt 1,46 %). GPU-Basisraten waren unverändert realistisch; weder PSU/Lüfter/RAM/Optik (`D.ops`, 0,8–2,5 %/Server-Jahr) noch Auto-Reparatur erzeugen Folgedefekte in relevanter Höhe. **Messwerte (10 Seeds gepoolt, 12 Monate, 2 Racks):** | Größe | Vorher (v5) | Nachher | |---|---|---| | HDD-AFR | 2,41 % | 1,53 % (Soll 1,6 %) | | Server-Hänger je Server und Jahr | 0,46–0,81 | 0,16–0,25 | | GPU-AFR (L40S) ohne Mining | 1,46 % | 1,46 % | | GPU-AFR mit Leerlauf-Mining | 2,71 % | 2,08 % (+~25 % durch Dauerlast) | | NVMe-AFR | – | 0,28 % | | RTX 4090 | – | 2,5 % | Faustwert: 0,13 Laufwerksausfälle je 100 Laufwerke und Monat → 10/Monat erst ab ~7 800 Laufwerken. **Änderungen:** * `data.js`: `D.hangYears = 4` (vorher implizit 1,3), `D.drvAfrK = 1.0` (vorher fest 1,4). * `engine.js`: Mining-Doppelzählung bei GPUs entfernt; Zähler `S.stats.drvFail`, `S.stats.hangN`, `S.stats.failHist` (Monatsliste `{m,drv,gpu,hang}`, max. 25 Einträge, lazy – kein neues Save-Format); `E.failStats(S)` (Flotte, Raten je Monat/Jahr). * `ui.js`: Wartung-Reiter mit Karte „Ausfallstatistik (letzte N Monate)“ (Zählung pro Spielzeit, tempounabhängig); bei Tempo ≥ 3 ein gesammelter Toast statt Einzel-Toasts. * Wirtschaft (Bot, 6 Seeds, 3 Jahre): Σ Netto 71 887 → 74 887, Uptime ~99,4 % – neutral. **Tests:** `tycoon-test/eng-fail.js` (11 Prüfungen: Tempo-Invarianz ×1–×4 × 10 Seeds, gepoolte AFR HDD/NVMe/GPU/Mining/4090, Laufwerke je 100 und Monat, failStats, Save-Roundtrip), `ui12.js` (echter Browser, Tempo 3 vs. 4 gegen direkte Engine), `ui11.js` ergänzt (Ausfallstatistik-Karte). Hilfsskripte `bal/speed-inv.js`, `bal/fail-rate.js`, `bal/fail-bot.js`, `bal/hang-cmp.js`. ## 11n. Welten-Auswahl: Welt 1 (gemeinsame Mehrspielerwelt) und Welt 2 (Einzelspieler) (Okt 2026, Save v5 unverändert) **Ziel.** Beim ersten Besuch (und über „🌍 Welt“ in der Kopfzeile jederzeit) wählt man die Welt. **Welt 2 = das bisherige Spiel unverändert** (Engine im Browser, eigenes Tempo, Spielstände je Konto oder als Gast lokal). **Welt 1 = eine persistente, serverautoritative, gemeinsame Welt** mit Echtzeit-Uhr, gemeinsamem Coin-Markt, knappen gemeinsamen Objekten, Rangliste, Chat, Spielermarktplatz und Marktereignissen. Welt 1 braucht ein Konto (kein Gastmodus). ### Architekturentscheidung: headless `engine.js` auf Node wiederverwenden * Die Regeln stehen schon vollständig in `engine.js` (ein Tick = 1 Spielstunde, `E.step`, Zustand `S` je Firma). Statt eine zweite Implementierung zu schreiben, lädt der Welt-Dienst **dieselbe `engine.js`/`data.js`** unter Node 22. Folge: Regeln, Balance und Fehlerbehebungen gelten automatisch in beiden Welten, Client-Vorschau und Server rechnen identisch. * Jede Firma ist ein eigener Engine-Zustand `S`; die Welt hat eine „Pseudo-Firma“ `S0`, die nur die gemeinsamen Märkte (Coin-Kurse, Netzwerk-Schwierigkeit, Strompreis, Wetter-Ereignisse) simuliert. Welt-spezifische Änderungen in der Engine sind **No-Ops, solange `S.world` nicht gesetzt ist** → Welt 2 ist bitgleich zum Stand v5.1 (geprüft: identischer Zustand, `eng-new` 95/95, `eng-fail` 11/11). * Alternativen verworfen: (a) Neuentwicklung der Regeln auf dem Server (doppelte Wartung, Abweichungen), (b) Client rechnet und meldet Ergebnisse (nicht manipulationssicher), (c) Postgres statt SQLite (ein einzelner Prozess, wenige hundert Spieler → SQLite/WAL reicht, kein zusätzlicher Dienst). ### Komponenten (CT121) | Teil | Ort | Aufgabe | |---|---|---| | `tycoon-world.service` | `/opt/tycoon-world/` (`world.js`, `server.js`, `admin.js`, `engine.js`, `data.js`), Node 22 unter `/opt/node`, `127.0.0.1:5020`, läuft als `tycoon`, `ProtectSystem=strict`, `MemoryMax=900M` | Welt-Zustand im Speicher (autoritativ), Tick-Schleife, HTTP-API | | `/var/lib/tycoon-world/world.db` | SQLite, WAL, Rechte 0700 | Persistenz (write-through je Befehl/Tick-Block in einer Transaktion) | | `/var/lib/tycoon-world/backups/` | tägliche Sicherung 04:20 (`tycoon-world-backup.timer`, `VACUUM INTO`), 14 Tage | Wiederherstellung | | `/etc/tycoon-world/internal.key` | 0640 root:tycoon | Schlüssel für die interne Admin-/Purge-Schnittstelle (nur lokal) | | nginx `/tycoon/api/world1/` | → `127.0.0.1:5020/`, `limit_req 15 r/s, burst 60`, `/internal/` gesperrt (404) | Reverse-Proxy | | Flask `tycoon-api` (`:5010`) | unverändertes Konto-System (Argon2id, Session-Cookie) | Anmeldung für beide Welten; `/me` liefert zusätzlich `id` und `since` | **Konto-Bindung.** Der Welt-Dienst liest das `tyc_session`-Cookie und fragt Flask `GET /me` (Antwort 20 s zwischengespeichert). Konto-Nr. (`id`) + Anlagezeitpunkt (`since`) binden die Firma an das Konto; wird ein Konto gelöscht und neu angelegt, passt `since` nicht mehr (HTTP 409). Konto löschen ruft `POST /internal/purge` im Welt-Dienst (Firma, Chat, Angebote weg, Objekte frei). ### Zeitmodell * **1 Tick = 1 Spielstunde = `tickSec` Echtzeitsekunden. Standard: `tickSec = 150` → 1 Spieltag = 1 Echtzeit-Stunde** (konfigurierbar per `admin.js tick `; Pause/Fortsetzen halten die Uhr stetig). * Ziel-Tick = `tickBase + floor((jetzt − tsBase)/tickSec)`. Der Dienst tickt auch ohne Spieler; nach einem Neustart/Ausfall holt `advance()` verpasste Ticks in Scheiben (50–100) nach (**Offline-Nachlauf**: 5 h Stillstand → 120 Ticks, geprüft). Keine Pause-/Tempo-Schaltflächen in Welt 1; die Kopfzeile zeigt „nächste Stunde in mm:ss“. * Zeitzone: Spielkalender (Start 01.01.2027) ist unabhängig von Zeitzonen; Echtzeit-Angaben (Saison, Chat) werden im Browser lokal formatiert. ### Gemeinsamer Markt * Basiskurse (Zufallsbewegung, Halving, Netzwerk) kommen aus `S0` über `E._w1.mineMarket/mineNetwork/marketMonth`; **Effektivkurs = Basis · exp(imp)**, `imp` ist der Marktdruck je Coin (±1,2 begrenzt). * **Preiswirkung:** Verkauf von Betrag `x` (relativ zur Markttiefe `D`): Erlös brutto `D·(1−e^−x)`, Druck sinkt um `x`; Kauf: `x = ln(1 + B/D)`, Druck steigt. Erholung: Halbwertszeit 96 Ticks (4 Spieltage). Markttiefe `D = depthEur × 0,1` (bewusst klein, damit Spieler spürbar wirken). Alle Spieler sehen dieselbe Kurs- und Preishistorie. Hook: `E.w1mkt` in `mineSellCoin`/`mineBuy`. * **Coins kaufen/verkaufen** geht in **beiden** Welten (`E.mineBuy`, Reiter Krypto-Mining → Wallet): Welt 2 gegen den eigenen simulierten Markt (Spread 0,4 % + Gebühr 0,15 %), Welt 1 gegen den gemeinsamen. * **Wallets je Welt getrennt (Entscheidung):** Eine gemeinsame Geldbörse würde Welt 2 (eigenes Tempo, Speichern/Laden, Cheat-Möglichkeiten durch lokale Engine) mit der fairen Welt 1 koppeln und damit die Serverautorität aushebeln. Die Auswahl zeigt eine schreibgeschützte **Wallet-Übersicht** beider Welten. ### Gemeinsame knappe Objekte * Land (Flächen), Wasserkraft, Pumpspeicher sind **Weltangebote** (`objects`-Tabelle; Anfangsbestand 14/10/10, alle 3 Spielmonate +3/+2/+2, Obergrenze 24/12/12). Jedes Objekt hat höchstens einen Eigentümer. * Technik: Die Angebote werden als Klone in `S.ext.lmarket/hmarket/pmarket` jeder Firma eingeblendet (`lmt/hmt/pmt = S.tick`, die Engine erzeugt nie eigene); der Kauf läuft über die normalen Engine-Befehle. Nach jedem Befehl vergleicht der Dienst die Angebots-IDs: verschwunden → **atomar `claim(uid,id)`**; Verkauf/Pachtende/Abriss → `release`. Da der Dienst Befehle **synchron und einzeln** ausführt, gibt es keine Race-Conditions; die DB-Zeile wird in derselben Transaktion fortgeschrieben (Test: parallele Käufe über HTTP → genau ein Gewinner). * Weitere Engpässe: höchstens 6 Standorte je Firma; Hardware-Lieferkontingente sind **nicht** knapp modelliert (offener Punkt). ### Wettbewerb um Kunden Kunden werden nicht pro Firma gewürfelt, sondern nach Gewicht verteilt: `S._w1f = N^0,85 · b_i/Σb` mit `b_i = Preisindex^−2,2 · Verfügbarkeit(EMA)^6` (Reputation/Qualität wirken über die Engine). Ein Alleinspieler erhält Faktor 1 (identisch zu Welt 2). ### Fairness, Schutz, Insolvenz Neueinsteiger-Schutz 20 Spieltage (Ausfall-/Ereignisrate ×0,25), Startkapital 36 000 €, Standortlimit, Preisobergrenze im Marktplatz (≤ 130 % Buchwert, 5 % Gebühr). **Insolvenz** (Kasse < Schwelle, keine Einnahmen) → Objekte frei, Firma `insolvent`, Neustart per Button nach 1 h Wartezeit mit Startkapital. **Marktereignisse:** Hitzewelle, Strompreisschock, Lieferengpass, regionaler Hagel (PV-Flächen) — für alle Spieler gleich, Meldung im Nachrichtenreiter. **Saison:** `admin.js season "Name"` archiviert die Rangliste, setzt die Welt zurück. ### Server-Autorität und Anti-Cheat * Der Client sendet nur **Befehle** (`POST /cmd {fn,args}`), nie Werte. Erlaubt sind nur Funktionen aus der Whitelist `E.W1_CMDS`; `clean()` normalisiert Argumente (Typen, Tiefe ≤ 6, Listen ≤ 60, Strings ≤ 300, Prototyp-Namen wie `__proto__` verboten). Nach jedem Befehl prüft `sane(S)` (endliche Zahlen, Kredit ≤ Limit) und stellt bei Verstoß/Ausnahme den Snapshot wieder her (`undo`). * Engine-Härtung gefunden durch Fuzzing: `E.repay`/`E.takeLoan` akzeptierten negative Beträge (Kredit-/Geld-Exploit) – behoben (gilt auch für Welt 2). * Der Client simuliert in Welt 1 nichts; er zeigt eine **Vorschau** (gepatchte Engine-Mutatoren) und überschreibt sie mit dem Serverzustand (`/state`, `rev`/`tick`-Vergleich, kurze „same“-Antwort). Lokale Kassen-Manipulation wird beim nächsten Sync überschrieben (UI-Test). * Rate-Limits: je Konto 8 Befehle/s (Burst 40), State-Polling begrenzt, nginx 15 r/s je IP, Chat-Limit + Stummschaltung. CSRF: Header `X-Tycoon: 1`, Origin-Prüfung. Interne Schnittstelle nur mit Schlüssel und ohne Proxy-Header. ### Datenmodell (SQLite, WAL) `meta` (Kern: Tick, Marktdruck, Ereignisse, Konfiguration, Zufallsstand) · `players` (uid PK, since, Firma, Status, Zustand `S` als JSON, Kennzahlen, Zeiten) · `objects` (id, kind, Angebot JSON, owner; Index owner/kind) · `chat`, `reports` · `news` · `listings` (Marktplatz, Treuhand im Datensatz) · `audit` (7 Tage: Zeit, uid, Aktion, Ergebnis) · `seasons` (Archiv). Indizes auf Eigentümer/Art/Zeit; `PRAGMA journal_mode=WAL`, Schreiben gebündelt je Tick-Block und je Befehl in `BEGIN IMMEDIATE`. ### API (`/tycoon/api/world1/…`) Öffentlich: `GET info`. Mit Konto: `GET me`, `POST join {company,terms}`, `GET state[?rev&tick&o|full]`, `POST cmd`, `GET board?key=net|rev|cust|rep`, `GET news`, `GET/POST chat`, `POST chat/report`, `GET market`, `POST market/list|buy|cancel`, `POST company`, `POST restart`, `GET export`, `POST leave {confirm:"LEAVE"}`. Intern (nur 127.0.0.1 + Schlüssel): `/internal/admin`, `/internal/purge`. ### Betrieb und Betreiber-Werkzeuge `/opt/tycoon-world/admin.js` (Schlüssel aus `/etc/tycoon-world/internal.key`): `stats`, `players`, `reports`, `ban/unban/mute/unmute `, `announce`, `motd`, `delchat`, `handle`, `tick `, `pause/resume`, `open/close`, `backup`, `season "Name"`, `purge `, `release `. Überwachung: `journalctl -u tycoon-world` (keine Passwörter/IPs; Aufbewahrung 30 Tage), `admin.js stats`. **Wiederherstellung:** Dienst stoppen, `world1-*.db` aus `backups/` nach `world.db` kopieren (WAL-Dateien löschen), Dienst starten. **Zurücksetzen:** Dienst stoppen, `world.db*` löschen, starten (Tick 0, Saison 1). ### Last (gemessen, `tests/load-test.js`) 200 Spieler mit je 2 Racks/16 Servern: Tick-Berechnung inkl. Speichern und Rangliste **≈ 130 ms** je Spielstunde bei 150 000 ms Tick-Länge (< 0,1 % Auslastung), 7 Spieltage Offline-Nachlauf ≈ 3,8 s, Speicher ≈ 280 MB RSS, DB ≈ 10 MB (+ WAL), 100 Clients pollen 1×/s ohne Fehler (Median 1 ms, p95 2 ms), ≈ 1 000 Befehle/s. Zustand je Firma ≈ 37 KB JSON. ### Rechtliches und Datenschutz (Pflicht für Welt 1) Impressum (`/tycoon/impressum.html`, `noindex` per Meta-Tag und `X-Robots-Tag`; Adresse/E-Mail erst per JS aus kodierten Teilen, `