README: BBR auf dem sendenden Rechner

Ohne die Einstellung ruckelt der Stream, und die Ursache ist von außen nicht
zu erkennen: Es sieht nach zu wenig Bandbreite aus, ist aber der
Stau-Algorithmus, der auf den vollen Modempuffer hereinfällt.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013XVnRop5c3or3B8xE2hpgZ

README.md

@@ -146,6 +146,30 @@ Bitrate und Auflösung stehen in
 `~/.config/obs-studio/basic/profiles/filmabend/basic.ini` und werden nur
 beim ersten Mal geschrieben. Das Sendeziel aktualisiert das Skript jedes Mal.
 
+### Der sendende Rechner braucht BBR
+
+Einmalige Einstellung, ohne die der Stream ruckelt:
+
+```bash
+printf 'tcp_bbr\n' | sudo tee /etc/modules-load.d/bbr.conf
+printf 'net.core.default_qdisc=fq\nnet.ipv4.tcp_congestion_control=bbr\n' \
+  | sudo tee /etc/sysctl.d/99-bbr.conf
+sudo sysctl --system
+```
+
+Warum: Kabelanschlüsse puffern den Upload großzügig. Unter Last stieg die
+Latenz hier von 26 auf 181 ms, ohne einen einzigen Paketverlust. Der
+Standard-Algorithmus `cubic` liest den Latenzanstieg als Stau und drosselt.
+Eine einzelne Verbindung kam so auf 4,5 statt 25 Mbit/s — und RTMP nutzt
+genau eine. OBS warf daraufhin 45 % der Bilder weg.
+
+BBR misst stattdessen den tatsächlichen Durchsatz und lässt sich davon nicht
+täuschen. Danach: 0 % verworfen. `fq` gehört dazu, BBR braucht diese
+Warteschlange für seine Sendetaktung.
+
+Prüfen mit `sysctl -n net.ipv4.tcp_congestion_control` — es muss `bbr`
+antworten.
+
 Von Hand geht es auch:
 
 | Feld | Wert |